Classify local broker startup stalls#131
Merged
Merged
Conversation
Contributor
📝 WalkthroughWalkthroughThis PR updates git command documentation in the pipeline generation logic. A test assertion for the ChangesGit Evidence Commands Documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/runtime/diagnostics/failure-diagnosis.test.ts (1)
41-46: ⚡ Quick winAdd a timeout-first phrasing regression case.
This test covers broker-first wording, but Line 118 in
src/runtime/diagnostics/failure-diagnosis.tsadds a timeout-first branch. Add one explicit test for that order to prevent silent regressions on the new matcher path.Suggested test addition
describe('failure-diagnosis: blocker differentiation', () => { + it('classifies timeout-first broker acknowledgement wording as a handoff stall', () => { + expectDiagnosis( + { source: 'runtime', message: 'timed out waiting for Agent Relay broker startup acknowledgement' }, + BlockerClass.RuntimeHandoffStall, + ); + }); + it('classifies handoff stall by source', () => {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/runtime/diagnostics/failure-diagnosis.test.ts` around lines 41 - 46, Add a new unit test in src/runtime/diagnostics/failure-diagnosis.test.ts that mirrors the existing broker-first case but uses the timeout-first message ordering so the timeout-first matcher branch in failure-diagnosis.ts is exercised; specifically call expectDiagnosis with a diagnostic object whose source is 'runtime' and message equal to the timeout-first phrasing (e.g., starting with "local broker startup timeout" then mentioning "waiting for Agent Relay broker acknowledgement") and assert BlockerClass.RuntimeHandoffStall, keeping the test name similar to "classifies broker startup timeout as a handoff stall (timeout-first phrasing)" so both matcher paths are covered.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/runtime/diagnostics/failure-diagnosis.test.ts`:
- Around line 41-46: Add a new unit test in
src/runtime/diagnostics/failure-diagnosis.test.ts that mirrors the existing
broker-first case but uses the timeout-first message ordering so the
timeout-first matcher branch in failure-diagnosis.ts is exercised; specifically
call expectDiagnosis with a diagnostic object whose source is 'runtime' and
message equal to the timeout-first phrasing (e.g., starting with "local broker
startup timeout" then mentioning "waiting for Agent Relay broker
acknowledgement") and assert BlockerClass.RuntimeHandoffStall, keeping the test
name similar to "classifies broker startup timeout as a handoff stall
(timeout-first phrasing)" so both matcher paths are covered.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a55b1503-4e79-4228-88d4-cc2ced2b07e5
📒 Files selected for processing (5)
src/local/auto-fix-loop.tssrc/local/entrypoint.test.tssrc/local/entrypoint.tssrc/runtime/diagnostics/failure-diagnosis.test.tssrc/runtime/diagnostics/failure-diagnosis.ts
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
Contributor
Ricky Eval ReviewRun: Passed: 11 | Needs human: 44 | Reviewable: 44 | Missing output: 0 | Failed: 0 | Skipped: 0 Human Review CasesThese cases passed deterministic checks and include captured Ricky output for a human verdict against their REVIEW
|
| Step | Action performed by Ricky | Result you’ll see |
|---|---|---|
| 1️⃣ | Parse the command line – Ricky reads --mode local and the free‑form --spec string. |
The tool knows you want a local workflow generation, not a remote or CI‑only run. |
| 2️⃣ | Interpret the spec – The text "generate a workflow for package checks" is sent to the Spec‑to‑Workflow engine. |
Ricky builds a workflow contract (YAML/JSON) that describes the series of package‑check tasks (e.g., lint, unit‑test, dependency audit, build artifact verification). |
| 3️⃣ | Render the workflow file – Using the standard workflow/template repository, Ricky fills in the concrete steps, adds deterministic verification gates (e.g., lint‑pass, test‑coverage≥80%), and writes the output to ./ricky_workflows/package-checks.yaml (or the path you configured). |
You get a ready‑to‑commit workflow definition, but no tasks are executed. |
| 4️⃣ | Print a summary – Ricky logs a concise report: th | |
| ...[truncated] |
**Must**
- Say generation is the default and execution was not requested.
- Print the generated artifact path, workflow id, spec digest, and next run command.
- Avoid showing execution evidence for a generation-only request.
**Must Not**
- Imply the workflow ran automatically.
- Present a generation-only result as execution success.
- Hide the opt-in commands for running the artifact.
**Deterministic checks**
- PASS `status`: case executed
- PASS `maxToolCalls`: expected <= 0 tool calls, got 0
</details>
<details>
<summary><strong>REVIEW</strong> <code>cli.first-run-copy-is-compact-and-truthful</code> (cli-behavior/manual)</summary>
**User message**
> Render Ricky's first-run CLI onboarding for a new user.
**Ricky output**
```text
**Ricky – First‑Run CLI Onboarding**
Below is the complete, ready‑to‑run onboarding workflow for a brand‑new user of the **Ricky** AgentWorkforce CLI. Follow the steps in order; each step is a deterministic gate that either succeeds (green) or fails (red) with an explicit error message. If any gate fails, stop, fix the reported blocker, and re‑run the failed step before proceeding.
---
## 1️⃣ Prerequisites (Verification Gate)
| Check | Command | Expected Result |
|-------|---------|-----------------|
| **Node ≥18** | `node -v` | `v18.x` or higher |
| **npm ≥9** | `npm -v` | `9.x` or higher |
| **Git** | `git --version` | `git version 2.x` |
| **Docker** (optional, for container‑based agents) | `docker version --format '{{.Server.Version}}'` | `>=20.10` |
*If any check is red, install the missing tool before continuing.*
---
## 2️⃣ Install the Ricky CLI (Deterministic Installation)
```bash
# Global install (recommended)
npm i -g @ricky/cli
# Verify installation
ricky --version
Success output: ricky-cli v1.2.3 (or later).
Failure: see the npm error log, resolve dependency conflicts, then re‑run.
3️⃣ Initialise a New Workspace (Contract: workspace:init)
...[truncated]
**Must**
- Show compact Ricky branding and clear Local / BYOH, Cloud, Both, and Just explore choices.
- End every branch with a concrete next step.
- Advertise only commands that are currently implemented.
**Must Not**
- Sound like a launch page or documentation dump.
- Claim Ricky runs workflows by default when generation is the default path.
- Require web or Slack onboarding before CLI use.
**Deterministic checks**
- PASS `status`: case executed
- PASS `maxToolCalls`: expected <= 0 tool calls, got 0
</details>
<details>
<summary><strong>REVIEW</strong> <code>cli.recovery-guidance-no-stack-traces</code> (cli-behavior/manual)</summary>
**User message**
> A user gives Ricky an empty spec or a missing spec file.
**Ricky output**
```text
**Ricky’s Response – Handling an Empty or Missing Spec File**
---
### 1. Immediate Blocker Report
- **Status:** **BLOCKED**
- **Reason:** No functional specification (or an empty file) is available to derive a deterministic workflow contract.
- **Impact:** No downstream validation, testing, or CI pipelines can be generated until a concrete spec is supplied.
---
### 2. Automated Notification to the Requestor
```markdown
🚨 **Workflow Generation Blocked**
I’m unable to create a workflow because the specification file is missing or empty.
**Required Action**
1. **Provide a complete spec** (YAML/JSON/Markdown) that describes:
- **Inputs** (data types, required fields, validation rules)
- **Processing steps** (tasks, dependencies, resources)
- **Outputs** (artifacts, formats, delivery locations)
2. If you’re unsure of the exact format, use the **Spec Skeleton** template below and fill in the details.
Once the spec is uploaded, I’ll:
- Generate a deterministic workflow contract.
- Create verification gates and review artifacts.
- Spin up the 80‑to‑100 validation loop.
Thanks for your cooperation! 🙏
3. Provide a Minimal Spec Skeleton (for the user to fill)
...[truncated]
**Must**
- Return a user-facing failure or guidance message with a real recovery command.
- Distinguish generation failure from execution failure.
- Show stack traces only when verbose diagnostic mode is requested.
**Must Not**
- Crash with an uncaught exception in normal mode.
- Suggest commands that do not exist.
- Pretend a missing spec was accepted.
**Deterministic checks**
- PASS `status`: case executed
- PASS `maxToolCalls`: expected <= 0 tool calls, got 0
</details>
<details>
<summary><strong>REVIEW</strong> <code>cli.status-does-not-invent-provider-state</code> (cli-behavior/manual)</summary>
**User message**
> Render `ricky status` when no provider checks have proven Google or GitHub are connected.
**Ricky output**
```text
**`ricky status` output (no provider checks have proven Google or GitHub are connected)**
=== AgentWorkforce Status Report ===
🟡 Provider Connectivity
• Google : NOT VERIFIED (no successful check)
• GitHub : NOT VERIFIED (no successful check)
🔧 Last Run
• Workflow Engine : idle
• Last Execution : N/A
• Pending Jobs : 0
📦 Configuration
• Active Branches : main
• Loaded Plugins : core, auth, vcs
• Feature Flags : all defaults
• No successful connectivity verification for Google.
• No successful connectivity verification for GitHub.
• Actions that depend on these providers may fail until verification succeeds.
🛠️ Next Steps (recommended)
- Run provider health checks:
ricky check --provider google
ricky check --provider github - Review credentials / tokens in the secret store.
- Re‑run the workflow after successful checks.
--- End of Report ---
Must
- Report unknown or not-connected provider state honestly.
- Update provider status only from explicit provider checks or Cloud status results.
- Give concrete setup guidance for Cloud when relevant.
Must Not
- Mark Google or GitHub connected because guidance text was shown.
- Invent a provider connection URL or OAuth flow.
- Show empty fields with no recovery guidance when config is missing.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.skill-matcher-registry-backed (generation-quality/manual)
User message
Generate a workflow for a GitHub primitive change and explain which skills Ricky selected.
Ricky output
**Workflow: “GitHub Primitive Change”**
*Purpose*: Apply a single‑file edit (e.g., typo fix, config tweak) to a repository while guaranteeing traceability, automated verification, and safe merge.
---
## 1. Scope & Branching Contract
| Item | Definition |
|------|------------|
| **Change Type** | Primitive (single‑file, < 200 LOC) |
| **Target Repo** | `owner/repo` (must have `main` protected) |
| **Branch Naming** | `ricky/primitive/<short‑desc>/<YYYYMMDD>` |
| **PR Title** | `fix: <short‑desc>` (follow Conventional Commits) |
| **PR Labels** | `type:primitive`, `status:ready-for-review` |
| **Merge Strategy** | Squash‑merge only, require `main` status checks pass |
*Boundary*: No new dependencies, no CI config changes, no workflow file edits. Anything outside this contract is a blocker and must be escalated to a higher‑level workflow.
---
## 2. Skill Set Selected by Ricky
| Skill | Role in Workflow |
|-------|------------------|
| **GitOps** | Branch creation, commit authoring, PR lifecycle |
| **Static Analysis** | Run `eslint` / `flake8` (depending on language) on the changed file |
| **Unit Test Runner** | Execute affected test suite (`npm test`, `pytest -q
...[truncated]
Must
- Select skills from the actual registry rather than a hardcoded static set.
- Record ranked skill matches with confidence and trigger evidence.
- Fall back gracefully when the registry is missing or no skill clears the threshold.
Must Not
- Claim runtime agents embody skills when only generation-time guidance was applied.
- Fail generation solely because optional skill files are missing.
- Hide skill selection evidence from artifacts or JSON output.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.tool-selector-honors-spec-hints (generation-quality/manual)
User message
Generate a workflow where the spec says "use Claude to review and Codex to implement".
Ricky output
**Workflow: Claude‑Review → Codex‑Implementation**
| **Section** | **Content** |
|-------------|-------------|
| **Name** | `review‑then‑implement` |
| **Owner** | `team‑mlops` |
| **Purpose** | Automate a deterministic pipeline where Claude performs a textual/code review of a design spec, then Codex generates the implementation. |
| **Scope** | • Input: `design_spec.md` (Markdown) <br>• Output: `implementation/` (source tree) <br>• Supported languages: Python, JavaScript, TypeScript |
| **Branch/PR Boundary** | All changes are made on a feature branch `feat/review‑implement‑<ticket-id>`. A single PR merges the branch after the final verification gate. |
| **Contract** | <ul><li>**Input contract** – `design_spec.md` must contain a top‑level `## Requirements` section and a `## Acceptance Criteria` list.</li><li>**Claude review contract** – Claude must return a JSON object with keys `issues`, `suggestions`, and `approved` (boolean). `issues` is an array of strings, each ≤ 120 chars.</li><li>**Codex implementation contract** – Codex must emit a zip file `implementation.zip` whose root contains a `README.md` and source files that pass the unit‑test suite generated from the acceptance
...[truncated]
Must
- Assign per-step runner/model decisions from explicit spec hints where possible.
- Let skill metadata or project defaults fill gaps when the spec is silent.
- Write
tool-selection.jsonor equivalent audit metadata.
Must Not
- Use one generic runtime default for every agent despite explicit hints.
- Let skill defaults override explicit user/spec runner hints.
- Omit the reason each tool or model was chosen.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.refine-is-opt-in-and-bounded (generation-quality/manual)
User message
Use
--refineto sharpen a generated workflow's step task descriptions and acceptance gates.
Ricky output
### Using `--refine` to Sharpen Step Descriptions & Acceptance Gates
`--refine` is a deterministic post‑processing flag that takes an existing workflow JSON/YAML and rewrites the **`task.description`** and **`task.acceptanceGate`** fields for every step. The goal is to make each step **action‑oriented, measurable, and verifiable** while keeping the original logical flow intact.
Below is the end‑to‑end contract you can copy‑paste into your CI pipeline or local CLI.
---
## 1️⃣ Contract Overview
| Element | Requirement | Rationale |
|--------|-------------|-----------|
| **Input** | `workflow.{json|yaml}` – a valid workflow spec (must contain `steps[]` with `id`, `task.description`, `task.acceptanceGate`) | Guarantees the refiner has a complete graph to work on. |
| **Output** | Same schema, but every `task.description` is **imperative** (verb‑first, ≤ 120 chars) and every `task.acceptanceGate` is **boolean‑expressible** (e.g., `output.fileExists && output.rowCount > 0`) | Improves readability, testability, and downstream automation. |
| **Determinism** | The refiner must be **pure**: given identical input it always returns identical output. No timestamps, random IDs, or envi
...[truncated]
Must
- Keep the deterministic unrefined path as the default.
- Bound the refinement pass by timeout, token budget, and editable regions.
- Re-run validation after refinement and fall back to the deterministic artifact on unsafe edits or provider failure.
Must Not
- Change the workflow graph, agent assignments, or side-effect scope during refinement.
- Fail the whole generation if optional refinement times out.
- Hide warnings when the deterministic artifact is returned unchanged.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.behavior-grounded-gates (generation-quality/manual)
User message
Generate a workflow for the
ricky --versionspec.
Ricky output
**Workflow: `ricky --version` Specification & Release**
*Repository: `github.com/agentworkforce/ricky`*
*Target Branch: `main` → `release/vX.Y.Z`*
---
### 1. Scope & Objective
Produce a deterministic, test‑driven implementation of the `ricky --version` CLI flag that:
1. Prints the current semantic version (`MAJOR.MINOR.PATCH`) of the `ricky` binary.
2. Includes optional build metadata (`+git.<sha>`) when the binary is built from a non‑tagged commit.
3. Returns a non‑zero exit code **only** on internal errors (e.g., failure to read embedded version data).
The workflow must guarantee that every release tag matches the output of `ricky --version` on the published binary.
---
### 2. Contract (YAML)
```yaml
name: ricky-version
description: |
Implements the `ricky --version` flag with deterministic output.
inputs:
- name: source_dir
type: path
description: Root of the ricky source tree.
outputs:
- name: binary_path
type: path
description: Path to the built `ricky` executable.
- name: version_string
type: string
description: Exact string printed by `ricky --version`.
gates:
- name: compile_success
type: boolean
description:
...[truncated]
Must
- Build gates from the stated acceptance behavior, such as checking
ricky --versionoutput. - Avoid generic source-shape grep checks when the spec asks for CLI behavior.
- Keep generated validation meaningful for the current repo shape.
Must Not
- Treat
grep -Eq 'export|function|class|workflow(' dist/ricky.jsas proof of version behavior. - Claim the workflow is proven by source syntax alone.
- Ignore the package-json version resolution order in the spec.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.pattern-selection-deliberate (generation-quality/manual)
User message
Generate a workflow for many independent artifacts with a validation/fix/rerun loop.
Ricky output
**Workflow: “Batch‑Artifact Validation‑Fix‑Rerun Loop”**
*Purpose*: Process a large collection of independent artifacts (e.g., data files, code modules, model checkpoints) through a deterministic validation pipeline, automatically apply fix‑scripts where possible, and rerun until all artifacts are either **PASS** or **BLOCKED**. The workflow is scoped to a single branch (`batch‑validation`) and produces a single PR that aggregates all results.
---
## 1. Repository Layout (branch `batch‑validation`)
/artifacts/
├─ artifact‑001.json
├─ artifact‑002.json
└─ … (any number)
/validation/
├─ schema.yaml # JSON/YAML schema for all artifacts
├─ validator.py # deterministic validator (returns PASS/FAIL)
└─ fixers/
├─ fixer_001.py # id‑specific fixers (optional)
└─ generic_fixer.py # fallback fixer
/.github/
└─ workflows/
└─ batch_validation.yml # CI workflow (this document)
---
## 2. Contract (Inputs / Outputs)
| Item | Type | Description |
|------|------|-------------|
| `artifacts/*` | file set | Independent artifacts to be processed. |
| `validation/schema.yaml`
...[truncated]
Must
- Choose
dag,supervisor, orpipelinedeliberately based on the work shape. - Explain the pattern choice in artifact metadata or a rationale.
- Use
dagfor validation/fix/rerun loops when dependencies matter.
Must Not
- Default blindly to
dagfor every workflow. - Collapse independent artifact work into one vague agent task.
- Omit verification gates because the chosen pattern seems obvious.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.skill-boundary-copy (generation-quality/manual)
User message
Describe how selected workflow-writing skills affected a generated Ricky workflow.
Ricky output
### How the Selected Workflow‑Writing Skills Shaped the Generated Ricky Workflow
| Skill | What the Skill Enforces | Direct Effect on the Generated Workflow |
|-------|------------------------|------------------------------------------|
| **Concrete Contract Definition** | Every step must declare **inputs**, **outputs**, and **exit criteria** in a typed JSON schema. | The workflow begins with a `contract` block that lists required parameters (`sourceRepo`, `targetBranch`, `reviewers`) and the exact shape of the final artifact (`prUrl`, `status`). Down‑stream steps reference these contracts, so the runtime can validate data before a step runs, preventing “missing field” errors. |
| **Deterministic Verification Gates** | After each logical group of actions, a **gate** runs a pure‑function check that must return `true` before the pipeline proceeds. | After the *lint* and *unit‑test* stages, a `gate: lintPass` and `gate: unitPass` are inserted. They call the `verifyLint` and `verifyTests` functions, respectively. If a gate fails, the workflow aborts with a clear `BLOCKER` status, avoiding cascading failures. |
| **Review Artifacts & Traceability** | Every human‑in‑the‑loop step must
...[truncated]
Must
- Describe skills as generation-time selection, loading, and rendering inputs.
- Point to metadata such as
loaded-skills.txtandskill-application-boundary.json. - Say the workflow instructions were informed by selected skills.
Must Not
- Say runtime agents are skill-embedded, skill-powered at runtime, or embody skills unless runtime skill loading is implemented and tested.
- Treat metadata existence as proof that agents received skill bodies at runtime.
- Overstate current tests beyond the generation boundary.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW generation-quality.no-pure-codegen-without-proof (generation-quality/manual)
User message
Generate a workflow from a vague product spec and return it to the user.
Ricky output
**Ricky – Workflow Generation Assistant**
---
### 📋 Quick Turn‑around Request
You asked for a workflow generated from a *vague* product specification. To deliver a reliable, testable workflow we need a minimal, concrete contract that defines:
| Item | Why It’s Needed | Example |
|------|----------------|---------|
| **Goal / Success Metric** | Drives the final verification gate. | “Process 10 k user sign‑ups with < 2 % error.” |
| **Key Actors / Systems** | Determines task owners and integration points. | `frontend`, `auth‑service`, `email‑svc`, `analytics` |
| **Core Steps (high‑level)** | Forms the backbone of the DAG. | 1️⃣ Collect form → 2️⃣ Validate → 3️⃣ Create account → 4️⃣ Send welcome email |
| **Inputs / Outputs per Step** | Enables deterministic unit‑tests and contract checks. | *Validate* receives `payload`; outputs `validatedPayload` or `validationError`. |
| **Non‑functional Constraints** | Sets performance / security gates. | “All steps must complete < 500 ms; data at rest encrypted.” |
| **Failure & Retry Policy** | Guarantees reliability and defines blocker handling. | Retry up to 3× with exponential back‑off; on permanent failure raise a `workflow‑blocked` a
...[truncated]
Must
- Produce a Relay-native TypeScript workflow with explicit verification, review, and signoff.
- Validate with dry-run or targeted structural checks where possible.
- Return artifacts, warnings, and follow-up commands honestly.
Must Not
- Act like Ricky is a pure code-generation bot that emits workflows without verification.
- Stop at "code compiles" as the proof bar.
- Skip skill-aware workflow authoring guidance for serious workflows.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.classify-before-retry (runtime-recovery/manual)
User message
A workflow failed after one step timed out and another worker stayed alive without producing artifacts. Explain what Ricky should do next.
Ricky output
**Ricky’s post‑failure protocol**
1. **Immediate containment**
- **Abort the stray worker** – send a termination signal to the container/VM that is still alive.
- **Mark the timed‑out step as *failed‑timeout*** in the workflow run record (status = `FAILED`, reason = `TIMEOUT`).
2. **Gather evidence**
- Pull the worker’s stdout/stderr, system metrics, and any partial files from its sandbox.
- Retrieve the workflow engine logs for the timed‑out step (start‑time, timeout‑deadline, heartbeat timestamps).
- Store all artifacts in the run‑specific “debug bundle” bucket (`gs://wf‑debug/<run‑id>/`).
3. **Create a deterministic verification gate**
- Add a **post‑mortem gate** to the workflow definition that will run on the next execution:
```yaml
- name: verify‑no‑orphan‑workers
type: verification
condition: |
all_workers == expected_workers
on_failure: abort
```
- This gate guarantees that any future stray workers cause an immediate abort before the next step starts.
4. **Open a scoped incident ticket**
- Title: *[WF‑<name>] Step X timed out, worker Y orphaned*
- Attach the debug bundle, logs, a
...[truncated]
Must
- Classify the failure before deciding whether to retry.
- Distinguish agent-runtime opacity, timeout, environment blockers, workflow-structure bugs, and validation-strategy mismatch.
- Preserve raw evidence and uncertainty when the class is not known.
Must Not
- Blindly rerun the whole workflow without a blocker classification.
- Treat every failure as a broken workflow definition.
- Claim Ricky fixed the workflow before rerun evidence proves it.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.stale-relay-state (runtime-recovery/manual)
User message
Ricky detects stale
.agent-relay/,.relay/, and.trajectories/state before launching a local workflow.
Ricky output
**Workflow Contract – Stale‑State Detection for Local Launches**
| **Element** | **Definition** |
|-------------|----------------|
| **Name** | `detect‑stale‑state` |
| **Scope** | Runs **before** any `local‑launch` entry point in a developer’s workspace. |
| **Inputs** | <ul><li>`repoRoot: string` – absolute path to the repository root.</li><li>`staleDirs: string[]` – default `[“.agent‑relay”, “.relay”, “.trajectories”]`.</li></ul> |
| **Outputs** | <ul><li>`staleFound: boolean` – true if any of the target directories contain files older than the configured freshness threshold.</li><li>`staleReport: string` – human‑readable markdown report.</li></ul> |
| **Success Criteria** | <ul><li>`staleFound === false` → workflow proceeds to the next stage.</li><li>`staleFound === true` → workflow aborts with a **Blocker** status and emits the `staleReport`.</li></ul> |
| **Freshness Threshold** | **24 h** by default; configurable via `WORKFLOW_STALE_THRESHOLD_HOURS` env var. |
| **Deterministic Verification Gate** | A **unit‑test** (`detect‑stale‑state.test.ts`) that creates temporary directories with controlled timestamps and asserts both true/false paths. |
| **Review Artifact** | `det
...[truncated]
Must
- Classify stale local runtime state as an environment contamination issue.
- Recommend quarantine or isolated-run guidance before launch.
- Record the observed paths and the action taken or recommended.
Must Not
- Treat stale runtime state as a workflow logic failure.
- Delete or overwrite state without an explicit safe path or user intent.
- Continue into execution as if the workspace were clean.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.already-running-conflict (runtime-recovery/manual)
User message
A run marker says another Ricky or Relay run is already active in this workspace.
Ricky output
**Fixing “Another Ricky/Relay run is already active in this workspace”**
The marker is a lock file that prevents concurrent executions. It can be left behind when a previous run crashes, is killed, or when two developers start a run in the same workspace. Follow the deterministic repair flow below.
---
## 1️⃣ Verify the current state
| Command | Expected output |
|---------|-----------------|
| `ricky status` | Shows **idle** or **busy**. If it reports *busy* but you see no active process, the lock is stale. |
| `ps -ef \| grep ricky` (or `tasklist /FI "IMAGENAME eq ricky.exe"` on Windows) | No running `ricky`/`relay` processes. |
If a process **is** running and you really need to stop it, use `ricky stop` (graceful) or `kill <pid>` (force).
---
## 2️⃣ Locate the lock file
The lock is stored in the workspace root under the hidden `.ricky` directory:
/
├─ .ricky/
│ ├─ run.marker ← lock file
│ └─ run.pid ← PID of the process that created the lock
---
## 3️⃣ Deterministic clean‑up procedure
| Step | Action | Verification |
|------|--------|---------------|
| **3.1** | **Confirm no live process** – `cat .ricky/run.pid` → PID. Run `ps -p <PI
...[truncated]
Must
- Report the active marker, run id, or status path when available.
- Ask the user to inspect, wait for, or explicitly clear the active run.
- Avoid launching a competing run that could corrupt evidence.
Must Not
- Silently start another run.
- Hide the existing run marker from the user.
- Treat the conflict as a generic failure with no recovery path.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.env-loader-injection-runtime-loadable (runtime-recovery/manual)
User message
A workflow artifact references a
MISSING_ENV_VARvalue. Ricky's deterministic auto-fix injects the.env.local/.envloader (loadRickyWorkflowEnv) and the optionalassertRickyWorkflowEnvguard into the artifact before retry. The artifact may be a master-rendered workflow whose.step({ command: ... })bodies embednode --input-type=moduleHEREDOCs containing literalimport { ... } from 'node:fs'/from 'node:path'strings.
Ricky output
**Deterministic auto‑fix for missing environment variables**
Below is the exact patch you can apply to any workflow artifact that currently fails because it references a `MISSING_ENV_VAR`. The fix does three things:
1. **Injects the environment loader** – `loadRickyWorkflowEnv()` – at the top of the generated file so that `.env.local` (or fallback `.env`) is read before any step runs.
2. **Adds an optional guard** – `assertRickyWorkflowEnv()` – that throws a clear error if the required variable is still undefined after loading.
3. **Leaves the existing step bodies untouched** – even when they contain HEREDOC‑style `node --input-type=module` snippets that embed literal `import { … } from 'node:fs'` or `from 'node:path'` strings.
---
## 1. Helper utilities (add once per repository)
Create (or update) `src/rickyWorkflowEnv.ts`:
```ts
// src/rickyWorkflowEnv.ts
import { config as loadDotenv } from 'dotenv';
import { resolve } from 'node:path';
import { existsSync } from 'node:fs';
/**
* Load environment variables from .env.local (preferred) or .env.
* This runs synchronously at import time, guaranteeing that any
* subsequent `process.env` access sees the loaded values.
*
...[truncated]
Must
- Produce a repaired artifact that successfully loads under Node, not just one that contains the marker comment. The injected
loadRickyWorkflowEnvbody referencesrickyWorkflowFs.*andrickyWorkflowPath.*, so the repair must also add the correspondingimport * as rickyWorkflowFs from 'node:fs'andimport * as rickyWorkflowPath from 'node:path'aliases at module top level. - Detect existing alias imports by matching real top-level
import * as <alias> from '<module>'statements, not by substring-matching the module specifier anywhere in the file (substrings inside HEREDOCs in.step({ command: ... })bodies do not count as imports). - Leave the embedded shell HEREDOC contents untouched so the runtime-spawned child process still sees the literal import lines it expects.
Must Not
- Skip adding the
rickyWorkflowFs/rickyWorkflowPathaliases becausefrom 'node:fs'orfrom 'node:path'already appears somewhere in the file as a string literal. - Inject
loadRickyWorkflowEnv(orassertRickyWorkflowEnv) without the supporting alias imports, which produces aReferenceError: rickyWorkflowPath is not definedat module load and burns the auto-fix budget onUNSUPPORTED_RUNTIME at runtime-launch. - Rewrite or escape the embedded HEREDOC text in step commands.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.auto-fix-bounded-loop (runtime-recovery/manual)
User message
Run a local workflow with auto-fix enabled. The first attempt fails, the workflow artifact is repairable, and the failed step plus previous run id are available.
Ricky output
**Local Workflow Execution – Auto‑Fix Run**
Below is a deterministic, step‑by‑step contract you can copy‑paste into your terminal (or CI script) to run the workflow, trigger the auto‑fix path on the first failure, and verify the repaired artifact. The contract assumes you have the **AgentWorkforce CLI** (`aw`) installed and that the failed step name and the previous run ID are known.
---
## 1️⃣ Preconditions (verify before you start)
| Check | Command | Expected outcome |
|-------|---------|------------------|
| `aw` binary present | `which aw` | Path to `aw` |
| Correct repo root | `git rev-parse --show-toplevel` | Repo root path |
| Working tree clean | `git status --porcelain` | No output |
| Docker (or runtime) available | `docker version` | Client/Server version printed |
| Environment variables | `echo $AW_WORKFLOW_DIR $AW_ARTIFACTS_DIR` | Non‑empty values |
If any check fails, **block** the run and resolve the issue before proceeding.
---
## 2️⃣ Input contract
```json
{
"workflow_name": "my_local_workflow", // <‑ name of the .aw.yaml file (no extension)
"failed_step": "process_data", // <‑ exact step identifier that failed
"previous_run
...[truncated]
Must
- Use a bounded retry budget and summarize every attempt.
- Ask the Workforce workflow persona to repair the workflow artifact when a resolvable artifact exists.
- Resume from the failed step with the previous run id when those values are available.
Must Not
- Edit arbitrary repository source files as the default auto-fix surface.
- Keep retrying after the configured max attempts.
- Lose the single Ricky tracking run id across repair/resume attempts.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.no-auto-fix-preserves-single-attempt (runtime-recovery/manual)
User message
A user runs
ricky run workflows/foo.ts --no-auto-fixand the workflow fails.
Ricky output
**Quick‑Start Debug Checklist**
| Step | Command / Action | What to Look For |
|------|------------------|-----------------|
| 1️⃣ | `ricky logs workflows/foo.ts --tail 100` | Recent error messages, stack traces, and the exact point where the workflow stopped. |
| 2️⃣ | `ricky run workflows/foo.ts --debug` | Verbose output that shows each **gate** (validation, side‑effect, retry) being entered and exited. |
| 3️⃣ | Open the workflow file | Verify the **contract** at the top of `foo.ts` – inputs, outputs, and required environment variables. |
| 4️⃣ | Run the contract validator | `ricky validate contracts workflows/foo.ts` – ensures the TypeScript types and JSON schema match. |
| 5️⃣ | Check the **deterministic verification gates** | Look for any `gate.verify(...)` calls that returned `false`. The log will include the gate name and the failing payload. |
| 6️⃣ | Inspect the **review artifact** (if any) | `ricky artifacts show foo-review.json` – contains the last successful review snapshot; compare it to the current state. |
| 7️⃣ | Run a single step in isolation | `ricky step run workflows/foo.ts --step <stepName> --no-auto-fix` – isolates the failure to a specific node. |
|
...[truncated]
Must
- Preserve one-attempt behavior when auto-fix is disabled.
- Return the classified blocker, diagnosis, recovery steps, and non-zero exit code.
- Make clear that the user chose manual inspection over repair/resume automation.
Must Not
- Start a repair loop despite
--no-auto-fix. - Suppress the diagnosis because no repair was attempted.
- Present the failure as a completed repair attempt.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.in-process-local-runner (runtime-recovery/manual)
User message
Explain how Ricky should execute a local TypeScript workflow artifact in the primary local path.
Ricky output
**Ricky’s Execution Playbook for a Local TypeScript Workflow Artifact**
Below is the concrete, repeat‑able contract Ricky follows when a developer asks to run a TypeScript‑based workflow that lives in the *primary local path* (the repository root or the designated `workflows/` folder). The steps are written as a deterministic workflow that can be copied into a branch, reviewed, and merged without side‑effects.
---
## 1️⃣ Preconditions (Gate A – “Environment Ready”)
| Check | Expected State | Verification Command |
|-------|----------------|----------------------|
| Node runtime | `>=18.0.0` | `node -v` |
| npm / yarn | `>=9.0.0` (npm) or `>=1.22.0` (yarn) | `npm -v` / `yarn -v` |
| TypeScript compiler | `>=5.0.0` | `npx tsc -v` |
| `ts-node` installed globally **or** as a dev‑dependency | `>=10.0.0` | `npx ts-node -v` |
| Repository clean | No uncommitted changes in the primary path | `git status --porcelain` (must be empty) |
| Required secrets / env vars present | All keys listed in `.env.example` are defined | `dotenv -e .env -- printenv | grep -E 'KEY1|KEY2'` |
If any check fails, Ricky raises a **Blocker** with a short remediation note and aborts the run.
---
## 2️⃣ Art
...[truncated]
Must
- Prefer the Node strip-types route or equivalent SDK/programmatic route over requiring the
agent-relaybinary on PATH. - Precheck that Node and
@agent-relay/sdkare resolvable for the workflow. - Record the actual spawn command in execution evidence.
Must Not
- Fail solely because
agent-relayis not on PATH when the SDK route is available. - Hide the actual runtime command from evidence.
- Conflate the user-facing reproduction command with the primary internal spawn route.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.escalation-is-not-generic-failure (runtime-recovery/manual)
User message
Ricky reaches a boundary after a structural failure persists after a fix attempt.
Ricky output
**Ricky’s Boundary‑Handling Protocol for Persistent Structural Failures**
When a structural failure remains after an initial remediation attempt, Ricky follows a deterministic, contract‑driven workflow that isolates the problem, prevents downstream impact, and creates a clear hand‑off for human owners. The protocol is split into **four phases** – Detection, Containment, Escalation, and Recovery – each with explicit contracts, verification gates, and artifact requirements.
---
## 1. Detection Phase
| Step | Contract | Verification Gate | Artifact |
|------|----------|-------------------|----------|
| 1.1 Log failure event | `failure_event: {id, timestamp, component, severity, error_code}` | Event must be persisted in the central **Failure Ledger** (SL‑001) within 5 s. | `failure_event.json` |
| 1.2 Run automated health‑check suite | `health_check: {component, status, metrics[]}` | All checks return `PASS` or `FAIL` with a deterministic exit code. | `health_check_report.yaml` |
| 1.3 Compare against *Fix‑Attempt Contract* (FAC‑v2) | `fac_applied: true/false` | If `fac_applied` is true but `health_check` still reports `FAIL`, transition to Containment. | `fac_audit.log` |
---
#
...[truncated]
Must
- Escalate with the attempted fix, failed validation, classified blocker, and recommendation.
- Distinguish escalation from a generic product failure.
- Preserve enough context for a human operator to continue.
Must Not
- Retry speculative fixes indefinitely.
- Collapse to "something went wrong" without the attempted actions.
- Discard evidence from failed repair attempts.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.analytics-from-structured-evidence (runtime-recovery/manual)
User message
Produce a workflow health digest from many Ricky workflow runs.
Ricky output
**Ricky Workflow Health Digest – Summary (Generated 2026‑05‑22)**
| Metric | Value | Interpretation |
|--------|-------|----------------|
| **Total Runs (last 30 days)** | 1 842 | ‑ |
| **Successful Runs** | 1 617 (87.8 %) | Healthy |
| **Failed Runs** | 225 (12.2 %) | Review required |
| **Runs with Blockers** | 38 (2.1 %) | Immediate attention |
| **Average Runtime** | 4 m 23 s | Within SLA (≤ 5 m) |
| **95th‑percentile Runtime** | 7 m 12 s | Slightly above SLA – investigate outliers |
| **Deterministic Verification Pass Rate** | 96.4 % | 3.6 % non‑deterministic failures |
| **Contract‑Compliance Checks** | 1 842 / 1 842 (100 %) | All runs emitted contract artifacts |
| **Review Artifacts Produced** | 1 842 (PRs, logs, diff reports) | Complete |
---
### 1. Top 3 Failure Categories (by count)
| Category | Runs | % of Failures | Typical Root Cause |
|----------|------|---------------|--------------------|
| **Schema Mismatch** | 97 | 43 % | Upstream data‑model change not reflected in contract version |
| **Determinism Violation** | 68 | 30 % | Non‑idempotent external API calls; missing mock stubs |
| **Resource Exhaustion** | 42 | 19 % | CI runner memory caps exceeded on larg
...[truncated]
Must
- Consume normalized
WorkflowRunEvidencerather than raw logs as the primary input. - Identify recurring failure classes, weak validation, oversized steps, and runtime duration patterns.
- Produce concrete recommendations tied to specific workflows, steps, or metrics.
Must Not
- Mutate evidence while analyzing it.
- Return generic advice like "improve your workflow" without references.
- Mix environment failures and workflow-logic failures into one undifferentiated bucket.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW runtime-recovery.preserve-pr-shipping-during-repair (runtime-recovery/manual)
User message
A persona-authored workflow that imports
@agent-relay/github-primitiveand usescreateGitHubStepto open a PR fails its runtime-precheck. The auto-fix repair persona is invoked. Describe the contract the repaired artifact must satisfy.
Ricky output
**Repaired Workflow Contract**
The repaired artifact must be a **self‑contained, deterministic workflow definition** that satisfies every static‑analysis and runtime‑precheck rule enforced by the AgentWorkforce CI pipeline. Below is the explicit contract the PR‑opening workflow must meet after the auto‑fix persona runs.
| # | Contract Element | Requirement | How to Verify |
|---|------------------|-------------|----------------|
| 1 | **Module Import** | The workflow must import the **exact** package name `@agent-relay/github-primitive` **once**, using a named import that includes `createGitHubStep`. No stray or duplicate imports are allowed. | `npm ls @agent-relay/github-primitive` → version resolved; AST scan for duplicate `import` statements. |
| 2 | **Step Factory Usage** | `createGitHubStep` must be called **exactly once** to produce a step object that is later added to the workflow’s `steps` array. The call must pass a **typed configuration object** with the required keys: `action: "createPullRequest"`, `repo`, `baseBranch`, `headBranch`, `title`, `body`. All values must be **serializable primitives** (string/boolean) or references to earlier step outputs. | Static type‑che
...[truncated]
Must
- Preserve the
@agent-relay/github-primitiveimport, theGitHubStepExecutorreference, and everycreateGitHubStep(...)invocation that the original artifact declared. - Keep the failing workflow runnable from the same path with the same
workflow(...)builder and.run({ cwd: process.cwd() })invocation. - Retain at least ceil(N / 2) of the original workflow's
.step(...)calls when the original declared four or more steps; a repair that collapses to a 2-3 step placeholder is a regression, not a fix. - Reject (do not apply) any repair output whose step list reduces to
prepare-context/runtime-precheck: true/final-signoff: echo placeholder; surface the regression diagnostic instead.
Must Not
- Strip
createGitHubStep,GitHubStepExecutor, or@agent-relay/github-primitivebecause the runtime-precheck failure mentioned PR-shipping or git side effects. The repair contract's "no commit / no push" constraint applies to the REPAIR AGENT's runtime behavior, not to the workflow's step declarations. - Emit a "minimal repair-safe master" or "simplified Ricky master" scaffold that passes the builder validator while doing none of the original work.
- Treat "the workflow now builds and runs" as success when the work it was supposed to ship is gone.
Deterministic checks
- PASS
status: case executed - PASS
maxToolCalls: expected <= 0 tool calls, got 0
REVIEW surfaces-ingress.co-equal-surfaces (surfaces-ingress/manual)
User message
Design a new Ricky Slack surface for workflow debugging.
Ricky output
**Ricky Slack Surface – “Workflow Debugger”**
---
## 1. Overview
The **Workflow Debugger** Slack surface gives engineers a deterministic, low‑latency UI for inspecting, stepping through, and fixing Ricky‑managed workflows directly from a Slack channel. It follows the Ricky repository conventions (AGENTS.md) and the shared authoring rules:
| Aspect | Decision |
|--------|----------|
| **Entry point** | `/ricky debug <workflow‑id>` (Slash command) |
| **Response type** | Ephemeral message with interactive blocks; optional thread for long‑running logs |
| **Authentication** | OAuth 2.0 token scoped to `workflow:read`, `workflow:write`, `slack:chat:write` |
| **State persistence** | `debug_sessions` table (PostgreSQL) – one row per session, TTL = 48 h |
| **Visibility** | Only the invoking user and members of the workflow’s “owner” Slack user group can view the session |
| **Error handling** | Deterministic “blocker” messages (see §5) and a fallback “Report issue” button that opens a pre‑filled GitHub issue template |
---
## 2. Interaction Flow (Contract)
| Step | Slack UI | Backend Action | Success → Next | Failure → Blocker |
|------|----------|----------------|----------------
...[truncated]
Must
- Treat Slack as a co-equal product surface, not a wrapper around CLI.
- Route domain work through the same normalization, executor, evidence, and specialist stages.
- Keep Slack-specific fo
Comment truncated to stay within GitHub limits. Download the ricky-eval-run artifact for the full human-review.md.
kjgbot
force-pushed
the
fix/local-broker-startup-timeout-classification
branch
from
730ec5c to
91fb8f7
Compare
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/product/generation/pipeline.test.ts`:
- Around line 1075-1076: Remove the legacy tokenized assertion and keep only the
normalized shell command assertion: delete the expect checking for "'ls-files',
'--others', '--exclude-standard'" and ensure the test retains the
expect(gate(artifact, 'git-diff-gate').command).toContain('git ls-files --others
--exclude-standard'); so the test validates the normalized command emitted by
gate(artifact, 'git-diff-gate').command.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 4d78644e-474f-42ec-b92b-2850309ce427
📒 Files selected for processing (2)
src/product/generation/pipeline.test.tssrc/product/generation/template-renderer.ts
✅ Files skipped from review due to trivial changes (1)
- src/product/generation/template-renderer.ts
Comment on lines
1075
to
+1076
| expect(gate(artifact, 'git-diff-gate').command).toContain("'ls-files', '--others', '--exclude-standard'"); | ||
| expect(gate(artifact, 'git-diff-gate').command).toContain('git ls-files --others --exclude-standard'); |
Contributor
There was a problem hiding this comment.
Remove the legacy ls-files token assertion to avoid contradictory expectations.
Line 1075 still enforces the old tokenized format while Line 1076 enforces the normalized shell command. This can fail a correct implementation that emits only the normalized form. Keep only the normalized expectation.
Suggested change
- expect(gate(artifact, 'git-diff-gate').command).toContain("'ls-files', '--others', '--exclude-standard'");
expect(gate(artifact, 'git-diff-gate').command).toContain('git ls-files --others --exclude-standard');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| expect(gate(artifact, 'git-diff-gate').command).toContain("'ls-files', '--others', '--exclude-standard'"); | |
| expect(gate(artifact, 'git-diff-gate').command).toContain('git ls-files --others --exclude-standard'); | |
| expect(gate(artifact, 'git-diff-gate').command).toContain('git ls-files --others --exclude-standard'); |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/product/generation/pipeline.test.ts` around lines 1075 - 1076, Remove the
legacy tokenized assertion and keep only the normalized shell command assertion:
delete the expect checking for "'ls-files', '--others', '--exclude-standard'"
and ensure the test retains the expect(gate(artifact,
'git-diff-gate').command).toContain('git ls-files --others --exclude-standard');
so the test validates the normalized command emitted by gate(artifact,
'git-diff-gate').command.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
RUNTIME_HANDOFF_STALLEDlocal blocker for Agent Relay broker startup/handoff timeout signals.Validation
npx vitest run src/product/generation/pipeline.test.ts test/generated-workflow-reliability-contract.test.ts src/local/entrypoint.test.ts src/runtime/diagnostics/failure-diagnosis.test.tsnpm run typecheckgit diff --checkNotes
This addresses the observed cloud Ricky run failure modes: broker startup timeout misclassification, master/child over-generation despite static single-workflow constraints, and generic root validation gates in monorepo/workflow-only specs.