rocketride-org/rocketride-server

Problem Statement Gjalla does software-architecture observability and AI-coding-agent oversight — keeping humans in control as agent-written code evolves. RocketRide agents and pipelines have no node to query it or push to it, so pipelines that want architecture/spec state or drift findings as context have to hand-roll HTTP calls. Proposed Solution Add a tool_gjalla agent-tool node (classType tool, register filter), mirroring nodes/src/nodes/tool_github/ (same file layout: IGlobal.py, IInstance.py, client module, services.json, README.md, svg, requirements.txt). Known integration surface: API host: https://api.gjalla.io, API-key auth Official Python package exists on PyPI (gjalla) — evaluate wrapping it vs. calling the REST API directly; prefer the thinner dependency Discovery step first (their public API docs are thin): before coding, enumerate the endpoints the gjalla PyPI package calls (spec upload, architecture/requirements queries, agent-session reporting) and post the propo

Problem Statement RocketRide pipelines and agents currently have no way to pull code-review intelligence: a pipeline that assembles an engineering status report, or an agent asked "what did code review flag this sprint," has no node to call. CodeRabbit exposes exactly this over a small REST API. Proposed Solution Add a tool_coderabbit agent-tool node (classType tool, register filter), mirroring the existing tool_github node (nodes/src/nodes/tool_github/ — same file layout: IGlobal.py, IInstance.py, <name>_client.py, services.json, README.md, svg, requirements.txt). API basis (documented at https://docs.coderabbit.ai/api-reference/report-generate): Base URL: https://api.coderabbit.ai/api/v1 Auth: x-coderabbitai-api-key header (config field, secret) Core operation: POST /report.generate — developer-activity / review reports over a date range, with prompt template, grouping, and parameter filters Suggested tool operations (exposed to agents): generate_report — from/to dates, opti

body.id looks like an identifier and is not one. It is a pipe slot the engine reuses. Identity throughout is the begin event's continuum seq — that is what the run archive is keyed by, what an answer carries in chat, and what getTrace and traceSlice resolve. Filed from section 4.3 of the Rocket CRM runtime findings (docRevision 252). Part of the Rocket CRM build tracked in rocketride-ai/rocketride-saas#456. Mechanism A field named id on an event body reads as the event's or the run's identity. Keying anything on it produces collisions that look like data corruption, because a later run reuses the slot. Nothing at the point of use says otherwise. What we do today Key everything on the begin event's continuum seq, and never touch body.id. Ask Rename it, or document it at the point of use — a one-line fix upstream against a multi-hour debugging session for every app that assumes otherwise. Related #131, #133 (both closed) — document the apaevt_flow shape {id, op, pipes[], trace} fo

Description get_task_status() makes three different promises about what it returns, and they disagree. packages/client-python/src/rocketride/mixins/execution.py: async def get_task_status(self, token: str) -> TASK_STATUS: """ Returns: Dict containing status information: - state: Current execution state ... Example: status = await client.get_task_status(token) state = status.get('state') """ return await self.call('rrext_get_task_status', token=token) The annotation says TASK_STATUS, which is a pydantic BaseModel (types/task.py:295). The docstring and its example say Dict and call .get(), which a BaseModel does not have. The body returns whatever self.call() yields, validated into neither. A caller following the docstring writes status.get('state'); a caller following the type hint writes status.state. Only one can work at a time and nothing says which. We hit this in an ingest health check: handling one shape reported state=None compl

Description packages/docs/scripts/lib/gather.js skips any node README that does not contain the <!-- ROCKETRIDE:GENERATED:PARAMS START --> marker, treating it as prose rather than a documentation page: if (!content.includes(GENERATED_START)) continue; // legacy README, not a doc nodes/scripts/gen-node-tables.mjs applies the same rule in resolveDocPath(), returning null unless the README already carries the marker. Four nodes have no markers, so they are skipped by both. They have no page on the docs site at all, and their reference blocks are never generated: cloud_tts (2 services) landing_ai (2 services) tool_mem0 (1 service) tool_n8n (1 service) All four are registered, shipping nodes with services*.json, so each has configurable parameters that users cannot currently discover from the documentation. 114 of the other 118 node READMEs carry the markers and publish normally. The generator reports this only as a silent count — skipped 17 without a co-located doc — with no indicat