fix(generation): replace deprecated harness-kit with persona-kit adapter#137
Merged
Conversation
…persona-kit adapter harness-kit is deprecated; persona-kit is its successor. The critical difference: persona-kit's buildNonInteractiveSpec uses the correct codex flags — no --ask-for-approval, which was removed in codex 0.1.77+ and caused every codex agent step to exit immediately with a parse error. Changes: - Add src/product/generation/persona-kit-runner.ts: a thin adapter that provides the same useRunnablePersona / useRunnableSelection / makeRunnablePersonaContext interface, backed by persona-kit's buildNonInteractiveSpec for arg building and inline subprocess spawning (ported from harness-kit's runner.ts). - loadWorkforcePersonaModule: load the local adapter instead of dynamically importing @agentworkforce/harness-kit. - ricky-local-persona-resolver: defaultLoadRunnableSelectionModule loads the local adapter instead of @agentworkforce/harness-kit. - Replace @agentworkforce/harness-kit with @agentworkforce/persona-kit in package.json. - Update two tests that tested harness-kit import-failure paths: those paths no longer exist; replaced with a test asserting the adapter resolves correctly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe PR migrates from ChangesHarness-kit to Persona-kit Migration
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
✨ 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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request replaces the deprecated @agentworkforce/harness-kit dependency with @agentworkforce/persona-kit and introduces a new adapter module, persona-kit-runner.ts, to maintain backward compatibility. Feedback on the new runner adapter suggests switching from the exit event to the close event on the spawned child process to ensure stdio streams are fully flushed, utilizing the native AbortSignal.any() API to prevent potential memory leaks from uncleaned event listeners, and wrapping the execution in a try...finally block to guarantee that skill cleanup commands are always executed even if the main task fails or is aborted.
| stderr += text; | ||
| options.onProgress?.({ stream: 'stderr', text }); | ||
| }); | ||
| child.on('exit', (code) => finish(code)); |
There was a problem hiding this comment.
Using the exit event can lead to race conditions where the process terminates but its stdio streams (stdout/stderr) have not finished flushing their buffered data. This can result in truncated output.
Switching to the close event ensures that all stdio streams are completely closed and read before resolving the promise. Any potential hangs from half-open pipes are already safely mitigated by the watchdog (waitForWriterWithWatchdog) in the caller.
child.on('close', (code) => finish(code));
Comment on lines
+104
to
+114
| function anySignal(signals: (AbortSignal | undefined)[]): AbortSignal | undefined { | ||
| const active = signals.filter((s): s is AbortSignal => s !== undefined); | ||
| if (active.length === 0) return undefined; | ||
| if (active.length === 1) return active[0]; | ||
| const controller = new AbortController(); | ||
| for (const signal of active) { | ||
| if (signal.aborted) { controller.abort(signal.reason); break; } | ||
| signal.addEventListener('abort', () => controller.abort(signal.reason), { once: true }); | ||
| } | ||
| return controller.signal; | ||
| } |
There was a problem hiding this comment.
The custom anySignal implementation adds 'abort' event listeners to the input signals but never removes them if the returned signal is not aborted. This can lead to memory leaks if the input signals are long-lived.
Since the project target is Node.js >= 22.14.0, you can leverage the native AbortSignal.any() API, which is more efficient, standard, and automatically handles cleanup.
function anySignal(signals: (AbortSignal | undefined)[]): AbortSignal | undefined {
const active = signals.filter((s): s is AbortSignal => s !== undefined);
if (active.length === 0) return undefined;
if (active.length === 1) return active[0];
return AbortSignal.any(active);
}
Comment on lines
+251
to
+298
| // Install skills if requested | ||
| if (sendOptions.installSkills === true && install.commandString !== ':') { | ||
| const installResult = await spawnCapture(install.command[0], install.command.slice(1), { | ||
| cwd, | ||
| env: callerEnv, | ||
| signal, | ||
| timeoutSeconds: sendOptions.timeoutSeconds, | ||
| onProgress: sendOptions.onProgress, | ||
| }); | ||
| if (installResult.status !== 'completed' || (installResult.exitCode ?? 0) !== 0) { | ||
| return { | ||
| status: installResult.status === 'completed' ? 'failed' : installResult.status, | ||
| output: installResult.stdout, | ||
| stderr: installResult.stderr, | ||
| exitCode: installResult.exitCode, | ||
| durationMs: Date.now() - startedAt, | ||
| }; | ||
| } | ||
| } | ||
|
|
||
| const result = await spawnCapture(bin, spec.args, { | ||
| cwd, | ||
| env: callerEnv, | ||
| signal, | ||
| timeoutSeconds: sendOptions.timeoutSeconds, | ||
| onProgress: sendOptions.onProgress, | ||
| }); | ||
|
|
||
| const status = | ||
| result.status === 'completed' && (result.exitCode ?? 0) !== 0 ? 'failed' : result.status; | ||
|
|
||
| // Cleanup skills after execution | ||
| if (sendOptions.installSkills === true && install.cleanupCommandString !== ':') { | ||
| await spawnCapture(install.cleanupCommand[0], install.cleanupCommand.slice(1), { | ||
| cwd, | ||
| env: callerEnv, | ||
| signal: undefined, | ||
| timeoutSeconds: 30, | ||
| }).catch(() => undefined); | ||
| } | ||
|
|
||
| return { | ||
| status, | ||
| output: result.stdout, | ||
| stderr: result.stderr + (cancelReason ? `\n${cancelReason}` : ''), | ||
| exitCode: result.exitCode, | ||
| durationMs: Date.now() - startedAt, | ||
| }; |
There was a problem hiding this comment.
If the main execution fails, throws an error, or is aborted/cancelled, the cleanup command for installed skills is never executed. This can leave stale files or processes in the workspace.
Wrapping the execution in a try...finally block guarantees that the cleanup command is always executed if an installation was attempted.
let shouldCleanup = false;
try {
// Install skills if requested
if (sendOptions.installSkills === true && install.commandString !== ':') {
shouldCleanup = true;
const installResult = await spawnCapture(install.command[0], install.command.slice(1), {
cwd,
env: callerEnv,
signal,
timeoutSeconds: sendOptions.timeoutSeconds,
onProgress: sendOptions.onProgress,
});
if (installResult.status !== 'completed' || (installResult.exitCode ?? 0) !== 0) {
return {
status: installResult.status === 'completed' ? 'failed' : installResult.status,
output: installResult.stdout,
stderr: installResult.stderr,
exitCode: installResult.exitCode,
durationMs: Date.now() - startedAt,
};
}
}
const result = await spawnCapture(bin, spec.args, {
cwd,
env: callerEnv,
signal,
timeoutSeconds: sendOptions.timeoutSeconds,
onProgress: sendOptions.onProgress,
});
const status =
result.status === 'completed' && (result.exitCode ?? 0) !== 0 ? 'failed' : result.status;
return {
status,
output: result.stdout,
stderr: result.stderr + (cancelReason ? '\n' + cancelReason : ''),
exitCode: result.exitCode,
durationMs: Date.now() - startedAt,
};
} finally {
// Cleanup skills after execution
if (shouldCleanup && install.cleanupCommandString !== ':') {
await spawnCapture(install.cleanupCommand[0], install.cleanupCommand.slice(1), {
cwd,
env: callerEnv,
signal: undefined,
timeoutSeconds: 30,
}).catch(() => undefined);
}
}![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 6 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
- exit → close: use 'close' event so stdio streams are fully drained before resolving; 'exit' can fire while pipes still have buffered data - anySignal: replace manual listener loop with AbortSignal.any() (Node ≥ 20.3) — native implementation handles listener cleanup automatically, eliminating the memory leak on long-lived input signals - skills cleanup: wrap main spawn in try/finally so cleanup command always runs even when execution throws, is aborted, or is cancelled - profile: pass options.profile through to usePersona() so callers can actually select a routing profile via RunnablePersonaOptions.profile Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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 taken by Ricky | Result you’ll see |
|---|---|---|
| 1️⃣ | Parses the command‑line arguments. | Recognises --mode local and the free‑form --spec string. |
| 2️⃣ | Enters spec‑only mode (the default when --run is omitted). |
No execution engine is started; Ricky only builds the workflow contract. |
| 3️⃣ | Calls the workflow authoring engine to translate the natural‑language spec into a concrete workflow definition (YAML/JSON) that follows the AgentWorkforce contract schema. | You receive a workflow file (e.g., package-checks.workflow.yaml) printed to STDOUT or saved to the path you specify with --out. |
| 4️⃣ | Performs deterministic verification gates on the generated contract: • Schema validation • Dependency graph sanity check • Required‑artifact presence • No circular references |
If any gate fails, Ricky aborts with a clear error message and a blocker report (e.g., “Missing required step install-deps”). |
| 5️⃣ | Emits a **revie | |
| ...[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, copy‑and‑paste ready onboarding workflow that a new user should run the first time they invoke the `ricky` CLI. It follows the **Ricky repository conventions** (AGENTS.md), the **workflow standards** (deterministic gates, review artifacts, 80‑100 validation loops), and the **shared authoring rules** (scoped branches/PRs, honest blocker reporting).
---
## 1️⃣ Create a Scoped Onboarding Branch
```bash
# From the root of the Ricky repo
git checkout -b onboarding/first‑run‑<your‑username>
All onboarding changes stay isolated until the final PR is merged.
2️⃣ Install the CLI (if not already)
# Recommended: use the official installer script
curl -fsSL https://ricky.dev/install.sh | bash
# Verify installation
ricky --version
# Expected output: ricky v0.9.3 (or later)Deterministic verification gate: the version string must match the latest release tag in CHANGELOG.md.
3️⃣ Initialise the Local Workspace
ricky init \
--workspace ./ricky-workspace \
--config ./ricky-workspace/.ricky.yaml./ricky-workspaceis the root for all generated artifacts.- The command c
...[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 Standard Response to an Empty or Missing Spec File**
---
### 1. Immediate Detection & Blocker Report
| Step | Action | Output |
|------|--------|--------|
| **1.1** | Verify the presence of the spec file at the path declared in the workflow manifest. | If `fs.existsSync(path)` returns **false** → **Blocker**. |
| **1.2** | If the file exists, read its contents and check for non‑whitespace characters. | If `content.trim().length === 0` → **Blocker**. |
| **1.3** | Emit a deterministic **Blocker Report** (JSON) to the CI console and to the `#workflow‑alerts` channel. | ```json { "type":"BLOCKER","reason":"Missing or empty spec","file": "<path>", "timestamp":"${ISO}" } ``` |
> **Rule** – No downstream steps may run while a blocker is open.
---
### 2. Auto‑Generate a Minimal Placeholder Spec
*(Only after the blocker is acknowledged by a reviewer or the owner)*
| Step | Action | Artifact |
|------|--------|----------|
| **2.1** | Create a new branch `spec/placeholder‑<timestamp>` from `main`. | Branch name follows `spec/placeholder-YYYYMMDD-HHMMSS`. |
| **2.2** | Populate `<workflow>.spec.yaml` with the **Spec Skeleton** (see below). | File added to the branch. |
| **2
...[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
REVIEW cli.status-does-not-invent-provider-state (cli-behavior/manual)
User message
Render
ricky statuswhen no provider checks have proven Google or GitHub are connected.
Ricky output
**`ricky status` output (no provider checks have proven Google or GitHub are connected)**
=== AgentWorkforce – Runtime Status ===
🟡 Provider Connectivity
• Google : NOT VERIFIED (no successful health‑check)
• GitHub : NOT VERIFIED (no successful health‑check)
✅ Core Services
• Scheduler : RUNNING
• Queue : ACTIVE
• Metrics : COLLECTING
• Provider health checks pending or failed for Google and GitHub.
• Workflow execution that depends on external provider APIs may be blocked.
🛠️ Next Steps (recommended)
- Run provider health checks:
ricky provider check --name google
ricky provider check --name github - Verify OAuth / token configuration for each provider.
- Review the provider logs:
ricky logs --provider google
ricky logs --provider github - If credentials are missing or expired, re‑authenticate:
ricky provider auth --name google
ricky provider auth --name github - Re‑run
ricky statusafter successful checks.
🗒️ Last Updated: 2026‑05‑29 14:32 UTC
*Interpretation*: The system is up, but without a confirmed connection to Google or GitHub,
...[truncated]
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 reproducible review, automated testing, and deterministic merge.
---
## 1. Scope & Branching Contract
| Item | Definition |
|------|------------|
| **Change Type** | Primitive – one file, ≤ 200 lines changed, no schema migrations. |
| **Source Branch** | `feature/primitive‑<short‑desc>` created from the latest `main`. |
| **Target Branch** | `main`. |
| **PR Title Pattern** | `fix: <short‑desc>` (e.g., `fix: correct typo in README`). |
| **PR Description Template** | <ul><li>What was changed?</li><li>Why (link to ticket/issue)</li><li>Impact assessment (none / low / medium)</li></ul> |
| **Branch Lifetime** | Must be merged or closed within 48 h of creation. |
| **Merge Strategy** | **Rebase‑and‑merge** – keeps linear history for primitive changes. |
| **Rollback Policy** | If post‑merge verification fails, revert the commit via `git revert <sha>` and open a new PR. |
---
## 2. Deterministic Verification Gates
| Gate # | Trigger | Action | Success Criteria | Owner |
|--------|---------|--------|------------------|-------|
|
...[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 Title:** `review‑and‑implement‑claude‑codex`
**Purpose**
Automatically route a feature request through a Claude‑based review step, then hand‑off the approved design to Codex for code generation. The workflow enforces deterministic verification gates and produces audit‑ready artifacts for each stage.
---
## 1. Contract (YAML)
```yaml
name: review-and-implement-claude-codex
description: |
Takes a textual feature spec, uses Claude to produce a design review,
then passes the approved design to Codex for implementation.
trigger:
- type: manual
inputs:
spec: string # raw feature description
repo: string # target GitHub repo (owner/repo)
branch: string # base branch for PR
outputs:
- type: artifact
name: design_review
format: markdown
- type: artifact
name: generated_code
format: zip
- type: artifact
name: implementation_pr
format: url
gates:
- name: review_approval
type: boolean
description: Claude must return “APPROVED” in the review summary.
- name: codex_success
type: boolean
description: Codex must emit a non‑empty zip and pass unit‑test suite.
validation_loop
...[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 a **generated workflow JSON** (or YAML) and returns a **tighter, review‑ready version**. It focuses on two things:
| Target | What `--refine` does |
|--------|----------------------|
| **Task descriptions** | • Removes vague verbs (“do”, “handle”). <br>• Adds concrete inputs, outputs, and success criteria. <br>• Enforces the *“who‑does‑what‑when‑how”* template. |
| **Acceptance gates** | • Converts informal “check” statements into explicit verification predicates (e.g., `assert len(output) > 0`). <br>• Inserts deterministic “gate” objects with `type`, `condition`, and `timeout`. <br>• Adds a **verification‑loop** count (default 80‑100) to guarantee repeatability. |
---
## 1. Basic Invocation
```bash
awf generate --template my_template.yaml --output workflow.json
awf refine --input workflow.json --output workflow_refined.json
awf= AgentWorkforce CLI.--inputpoints to the raw workflow you just generated.--outputis the refined artifact you will submit for review.
2. What the Refined Output Looks Like
Before
...[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
</details>
<details>
<summary><strong>REVIEW</strong> <code>generation-quality.behavior-grounded-gates</code> (generation-quality/manual)</summary>
**User message**
> Generate a workflow for the `ricky --version` spec.
**Ricky output**
```text
**Workflow: `ricky --version` Specification & Delivery**
*Repository:* `github.com/agentworkforce/ricky`
*Target Branch:* `main` → `feat/version‑spec`
---
## 1. Scope & Acceptance Criteria
| ID | Requirement | Success Metric |
|----|-------------|----------------|
| V‑001 | The CLI must expose a `--version` flag that prints the current semantic version (`MAJOR.MINOR.PATCH`) to **stdout** and exits with code 0. | Exact string match to `ricky vX.Y.Z` (no trailing newline required). |
| V‑002 | The version string must be sourced from the **single source of truth** in `src/version.py` (`__version__ = "X.Y.Z"`). | Test reads `__version__` and compares to CLI output. |
| V‑003 | The flag must be discoverable via `ricky -h` / `ricky --help`. | Help text contains “`--version` Show program’s version number and exit”. |
| V‑004 | The implementation must be **platform‑agnostic** (Linux, macOS, Windows). | CI runs on all three OS matrices and passes. |
| V‑005 | No new runtime dependencies may be introduced. | `pip‑freeze` unchanged except for version bump. |
| V‑006 | Documentation in `docs/cli.md` must include a **Version** section with example output. | Markdown contains “`$ ric
...[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 & Auto‑Fix Loop”**
*Purpose*: Process a large set of independent artifacts (e.g., data files, config bundles, code modules) through a deterministic validation stage, apply automated fixes where possible, and re‑run until all artifacts pass or a blocker is reported.
---
## 1. High‑Level Contract
| Element | Description |
|---------|-------------|
| **Input** | `artifact_set: List[ArtifactRef]` – each `ArtifactRef` contains a stable URI, checksum, and optional metadata. |
| **Output** | `validated_set: List[ArtifactRef]` – all artifacts that have passed validation. <br>`failed_set: List[ArtifactRef]` – artifacts that reached the blocker limit. |
| **SLA** | ≤ 80 % of artifacts must be auto‑fixed within **3** validation‑fix‑rerun cycles. |
| **Determinism** | All steps are pure functions of the artifact content and version‑controlled scripts. No hidden state. |
| **Idempotency** | Re‑running the workflow on the same `artifact_set` yields identical `validated_set`/`failed_set`. |
| **Safety Gate** | A **Blocker Report** is emitted if any artifact exceeds the max‑retry count or triggers a non‑recoverable error. |
---
## 2. Workflow D
...[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 Selected Workflow‑Writing Skills Shape a Generated Ricky Workflow
Below is a concise “skill‑impact map” that shows the direct effect each of the core Ricky authoring skills has on the structure, reliability, and reviewability of a generated workflow. The map is illustrated with a concrete example: a **“Customer‑Onboarding Email Campaign”** workflow that moves a new lead from **Lead Capture → Qualification → Welcome Series → Sales Handoff**.
| **Skill** | **What the skill does** | **Concrete effect on the generated workflow** | **Verification / Review artifact** |
|----------|------------------------|-----------------------------------------------|------------------------------------|
| **Deterministic Contract Definition** | Writes explicit input‑output contracts for every step (type, required fields, optional defaults). | Each node (`capture_lead`, `qualify`, `send_welcome`, `handoff`) declares a JSON schema. The downstream step can only start when the upstream schema validates, eliminating “missing‑field” runtime errors. | Auto‑generated **Contract Test Suite** (pytest + jsonschema) that runs on every PR. |
| **Gate‑Based Verification** | Inserts verification gates (p
...[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
Below is a **minimal, deterministic workflow skeleton** that you can flesh out once the missing product details are clarified.
It follows the AgentWorkforce conventions (AGENTS.md) and includes explicit contracts, verification gates, review artifacts, and a bounded PR scope.
---
## 1️⃣ Workflow Overview
| Stage | Owner | Goal | Primary Artifact |
|-------|-------|------|------------------|
| **1. Requirements Capture** | Product Owner (PO) | Translate the vague spec into concrete user stories & acceptance criteria | `spec‑v1.md` |
| **2. Design & Contract Definition** | System Architect | Draft component contracts, data schemas, and API surface | `design‑contract.md` |
| **3. Implementation** | Development Team | Build code that satisfies the contracts | Feature branch `feat/<ticket‑id>` |
| **4. Deterministic Verification** | QA Automation | Run contract‑based unit, integration, and property‑based tests | CI job `verify‑contracts` |
| **5. Review & Sign‑off** | Peer Reviewers + PO | Manual code review + acceptance‑criteria checklist | PR `#<pr‑id>` |
| **6. Release & Monitoring** | Release Engineer | Deploy to staging, then prod; set up health‑checks | Release tag `vX.Y.Z` |
|
...[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 Immediate Action Plan**
| Phase | Action | Why | Deliverable / Artifact |
|-------|--------|-----|------------------------|
| 1️⃣ Detect & Log | • Pull the latest run‑metadata from the orchestration layer (e.g., Airflow, Temporal, or internal scheduler). <br>• Identify the exact step that timed‑out (Step A) and the worker that remained alive (Worker B). <br>• Capture timestamps, exit codes, heartbeat logs, and any partial output directories. | Provides a deterministic, reproducible record of the failure – required for every post‑mortem. | `run‑<run‑id>.json` (full metadata) + `step‑A‑timeout.log`, `worker‑B‑heartbeat.log`. |
| 2️⃣ Classify the Blocker | • **Blocker Type:** *Hard* – the workflow cannot progress because the downstream step depends on artifacts that never materialized. <br>• **Root‑Cause Hypotheses:** (a) Step A exceeded its SLA; (b) Worker B hung due to resource deadlock or external service stall. | Determines the escalation path and the verification gate that must be satisfied before a retry. | `BLOCKER.md` – concise statement, severity (P0), and hypothesis list. |
| 3️⃣ Notify Stakeholders | • Auto‑post a comment on the PR/branch that owns the workflow (
...[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
**Ricky – Stale‑State Detection for Local Workflow Launches**
*(Implementation contract, verification gates, and review checklist)*
---
## 1. Overview
Before any local workflow is started, Ricky must verify that the three runtime‑state directories used by the AgentWorkforce stack are **fresh**:
| Directory | Purpose | Stale‑state symptoms |
|-----------|---------|----------------------|
| `.agent‑relay/` | Holds the relay server socket files and temporary auth tokens. | Orphaned socket files, expired JWTs, leftover PID files. |
| `.relay/` | Stores the per‑agent message queue snapshots. | Queue files older than the last successful workflow run, mismatched sequence numbers. |
| `.trajectories/` | Persists step‑by‑step execution traces for debugging/replay. | Trace files whose `workflow_id` does not match the current launch, incomplete JSON lines, timestamps > 5 min in the past. |
If any of these directories contain stale artifacts, the launch is aborted, a **blocker report** is emitted, and the user is prompted to clean or reset the state.
---
## 2. Detection Workflow Contract
| Phase | Input | Output | Deterministic Gate |
|-------|-------|--------|--------------------|
...[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
**How to clear a “run marker says another Ricky or Relay run is already active in this workspace” error**
The marker is a lock file that Ricky creates at the start of a run to prevent concurrent executions. If a previous run crashed, was killed, or left the lock dangling, the next invocation will stop with the message you’re seeing.
Below is the deterministic, step‑by‑step repair workflow that satisfies the AgentWorkforce reliability contract (no hidden state, fully reproducible, and safe for shared workspaces).
---
## 1️⃣ Verify the current lock state
```bash
# Show the lock file (if any) and its contents
cat .ricky/run.marker 2>/dev/null || echo "No marker file"
If the file does not exist, the error is coming from a stale in‑memory lock; skip to step 3.
2️⃣ Inspect the PID stored in the marker
The marker contains a JSON payload, e.g.:
{
"pid": 12345,
"started_at": "2026-05-28T14:32:10Z",
"run_id": "ricky-20260528-abcde"
}# Extract the PID
PID=$(jq -r .pid .ricky/run.marker)
echo "PID recorded in marker: $PID"2.1 Check if the process is still alive
if ps -p $PID > /dev/null; then
echo "Process $PID is still
...[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, reproducible patch you can apply to any workflow artifact that currently fails because it references a `MISSING_ENV_VAR`. The fix injects the **Ricky environment loader** (`loadRickyWorkflowEnv`) and the **optional guard** (`assertRickyWorkflowEnv`) **once**, at the top of the generated file, and then re‑exports the original workflow unchanged. This guarantees that every `step({ command: … })` block – even those that embed a `node --input-type=module` HEREDOC with literal `import { … } from 'node:fs'` / `from 'node:path'` strings – runs with the required variables available.
---
## 1️⃣ Contract – What the patch guarantees
| ✅ | Guarantee |
|---|-----------|
| **Deterministic** | The same source → same patched output (no random IDs). |
| **Idempotent** | Re‑applying the patch on an already‑fixed artifact is a no‑op. |
| **Scope‑limited** | Only the top‑level module is touched; inner HEREDOCs remain untouched. |
| **Verification gate** | `assertRickyWorkflowEnv(['MISSING_ENV_VAR'])` throws a clear error if the variable is still absent after loading. |
| **Rollback‑safe** | The original workflow is re
...[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 concrete, step‑by‑step contract you can copy‑paste into your terminal (or CI script) to run the workflow, trigger the auto‑fix path, and verify the repaired artifact. All actions are scoped to a single branch (`auto‑fix/run‑<timestamp>`) and a single PR, keeping the change surface minimal.
---
## 1️⃣ Preconditions (verify before you start)
| Check | Command / Action | Expected result |
|-------|------------------|-----------------|
| **Workflow definition** | `cat .agentworkflows/<workflow‑name>.yml` | YAML is syntactically valid (run `yamllint` if needed). |
| **Failed step ID** | `echo "<failed‑step‑id>"` | Non‑empty string (e.g., `build:compile`). |
| **Previous run ID** | `echo "<prev‑run‑id>"` | Valid UUID or numeric ID that exists in the local run store (`.agentruns/`). |
| **Auto‑fix flag enabled** | `grep -i autoFix .agentworkflows/<workflow‑name>.yml` | `autoFix: true` present under `metadata`. |
| **Clean working tree** | `git status --porcelain` | No uncommitted changes. |
If any check fails, abort and fix the issue before proceeding.
---
## 2️⃣ Branch & PR scaffolding (deterministic boundaries)
```bash
# 1.
...[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
**Immediate troubleshooting checklist**
1. **Capture the failure output**
```bash
ricky run workflows/foo.ts --no-auto-fix 2>&1 | tee ricky-run.log
Keep ricky-run.log – it is the primary artifact for the next steps.
-
Locate the validation gate that stopped the run
The log will contain a line like:[VALIDATION] Gate <gate‑name> failed (error‑code: <code>)Note the exact gate name and error code – this is the deterministic verification point you will need to address.
-
Open a scoped review branch
git checkout -b fix/foo‑<gate‑name>-<timestamp>
Keep the branch limited to the files touched by the failing gate (usually the workflow file itself and any referenced module).
-
Create a minimal reproducible test
Add a unit test undertest/workflows/foo.test.tsthat invokes the same entry point with the same inputs. This test will become part of the 80‑to‑100 validation loop and guarantees that the fix is not a regression. -
Apply the fix (manual, because
--no-auto-fixwas used)
Typical categories of failure and corresponding manual fixes| Gate / error code | Typica
...[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
</details>
<details>
<summary><strong>REVIEW</strong> <code>runtime-recovery.in-process-local-runner</code> (runtime-recovery/manual)</summary>
**User message**
> Explain how Ricky should execute a local TypeScript workflow artifact in the primary local path.
**Ricky output**
```text
**Ricky’s Standard Procedure for Executing a Local TypeScript Workflow Artifact**
| Phase | Action | Details & Rationale |
|-------|--------|----------------------|
| **1️⃣ Identify the Primary Local Path** | `WORKFLOW_ROOT=$(git rev-parse --show-toplevel)/workflows` | The repository convention places all workflow artifacts under `workflows/`. Using `git rev-parse` guarantees the path is absolute and works from any sub‑directory. |
| **2️⃣ Resolve the Target Artifact** | `ARTIFACT=$WORKFLOW_ROOT/<relative‑path>/<workflow>.ts` | Replace `<relative‑path>/<workflow>.ts` with the user‑supplied location. Verify the file exists: `[[ -f $ARTIFACT ]] || { echo "❌ Artifact not found: $ARTIFACT"; exit 1; }`. |
| **3️⃣ Prepare the Execution Environment** | 1. **Node version** – enforce `>=18` via `nvm use 18` or `asdf`. <br>2. **Dependencies** – run `npm ci` (or `pnpm i --frozen-lockfile`) in `$WORKFLOW_ROOT` to guarantee a reproducible lockfile state. <br>3. **TypeScript runtime** – ensure `ts-node` is available (`npm list ts-node || npm i -D ts-node`). | Deterministic environment eliminates “works on my machine” failures and satisfies the **Verification Gate: Dependency Integrity**. |
| **
...[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 – Boundary‑Reached Protocol for Persistent Structural Failure**
When a structural failure remains after an attempted fix, the workflow must be halted, documented, and escalated in a deterministic, auditable way. Follow the contract below to keep the repository clean, the team informed, and the failure traceable.
---
## 1. Immediate Containment (Gate A)
| Action | Owner | Artifact | Deadline |
|--------|-------|----------|----------|
| **Abort the current branch** – rename it with the suffix `‑blocked` (e.g., `feature/x‑blocked`). | Agent (you) | Branch rename log (git commit message). | ≤ 5 min |
| **Create a “Blocker” issue** in the central tracker (e.g., GitHub Issues) using the **Blocker‑Template** (see below). | Agent | Issue #️⃣, linked to the blocked branch. | ≤ 10 min |
| **Notify the responsible domain owner** (via @mention in the issue). | Agent | Slack/Teams @‑mention. | ≤ 10 min |
### Blocker‑Template
🚨 Structural Failure Blocker
Branch: feature/x‑blocked
Original PR: #<PR‑number> (link)
Failure Symptom: <short description, e.g., “Infinite recursion in DataPipeline.transform()”>
Fix Attempted: , brief summary of
...[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
</details>
<details>
<summary><strong>REVIEW</strong> <code>runtime-recovery.analytics-from-structured-evidence</code> (runtime-recovery/manual)</summary>
**User message**
> Produce a workflow health digest from many Ricky workflow runs.
**Ricky output**
```text
**Ricky Workflow Health Digest – [Date Range]**
---
### 1. Executive Summary
| Metric | Value | Trend |
|--------|-------|-------|
| Total Runs (all workflows) | **1 842** | ↗︎ +12 % vs. prior period |
| Successful Runs | **1 617** | ↗︎ +9 % |
| Failed Runs | **225** | ↘︎ –18 % |
| Blocked Runs (manual intervention) | **38** | → steady |
| Avg. Cycle‑time (per run) | **4 m 27 s** | ↘︎ –15 % |
| Avg. Verification Gates Passed | **7.3 / 8** | ↗︎ +0.2 |
> **Health Rating:** **🟢 Good** – Success rate > 87 %, verification gate pass‑rate > 90 %. No systemic regressions detected.
---
### 2. Run‑Level Breakdown (Top 5 Workflows)
| Workflow | Runs | Success % | Avg. Cycle‑time | Gate Pass‑rate | Notable Issues |
|----------|------|----------|----------------|----------------|----------------|
| **Deploy‑Prod** | 312 | 94 % | 3 m 12 s | 8/8 | None |
| **Data‑Ingest‑ETL** | 278 | 88 % | 5 m 03 s | 7/8 | 2 gate failures (schema‑validation) |
| **Feature‑Flag‑Rollout** | 215 | 92 % | 2 m 45 s | 8/8 | None |
| **Security‑Scan** | 191 | 81 % | 6 m 18 s | 6/8 | 3 gate failures (dependency‑vuln) |
| **Analytics‑Report** | 164 | 97 % | 4 m 01 s | 8/8 | None |
*Workflows with **< 85 %** succe
...[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**
| **Section** | **Requirement** | **Verification Gate** | **Pass/Fail Indicator** |
|-------------|----------------|-----------------------|--------------------------|
| **1. Imports** | The workflow must import the **exact** package name `@agent‑relay/github-primitive` **once** and expose it under the identifier `github`. | ‑ Static lint check for a single `import` statement matching `import * as github from '@agent-relay/github-primitive'`. <br>‑ Package‑resolution test (`npm ls @agent-relay/github-primitive` returns a single version). | ✅ Exactly one matching import, no duplicate or missing import. |
| **2. Step Creation** | The workflow must call `github.createGitHubStep` **once** to produce a step that opens a PR. The call must include: <br>• `action: 'openPR'` <br>• `title`, `head`, `base`, and `body` fields (all non‑empty strings). <br>• `reviewers` (optional array of strings). | ‑ AST inspection: a CallExpression whose callee is `github.createGitHubStep` and whose first argument is an object literal containing the required keys. <br>‑ Runtime‑type guard: the step object returned must have a `run` method and a `metadata.type === 'github'`. | ✅
...[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”
**Purpose**
A dedicated Slack UI that lets engineers and product owners inspect, step‑through, and repair Ricky‑managed workflows in real time without leaving their channel. It surfaces deterministic verification gates, validation‑loop metrics, and blocker reports, while keeping PR/branch scope visible.
---
### 1. Interaction Model (Slack App)
| Command | Trigger | Payload | Response |
|---------|---------|---------|----------|
| `/rdebug list` | List all active workflows in the current repo | `{repo, branch}` | Table of `workflow_id`, `status`, `last_run`, `branch` |
| `/rdebug inspect <wf-id>` | Pull detailed state for a single workflow | `{wf_id}` | Collapsible block with: <br>• Current step <br>• Input/Output snapshots <br>• Verification gate results <br>• Validation‑loop count |
| `/rdebug step <wf-id> [--to <step>]` | Advance workflow manually (or jump) | `{wf_id, target_step?}` | Confirmation + updated state |
| `/rdebug pause <wf-id>` | Freeze automatic progression | `{wf_id}` | “Paused – will not auto‑advance until `/rdebug resume`” |
| `/rdebug resume <wf-id>` | Un‑pause | `{wf_id}` | “Resumed – next gate
---
_Comment truncated to stay within GitHub limits. Download the `ricky-eval-run` artifact for the full `human-review.md`._
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
1 participant
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.
Problem
@agentworkforce/harness-kitis deprecated. It has a critical bug in itsbuildInteractiveSpec/buildNonInteractiveSpecimplementation (harness.js): it generatescodex exec --ask-for-approval <policy>, a flag removed in codex 0.1.77+ (replaced by--sandbox/--dangerously-bypass-approvals-and-sandbox). This caused every codex agent step in generated workflows to exit immediately with a parse error, burning the full--auto-fixretry budget (~hours per spec in overnight runs).The successor package
@agentworkforce/persona-kitships the fixedbuildNonInteractiveSpecthat does not generate--ask-for-approval.Fix
Add
src/product/generation/persona-kit-runner.ts— a thin adapter that provides the sameuseRunnablePersona/useRunnableSelection/makeRunnablePersonaContextinterface ricky expects, backed by:@agentworkforce/persona-kit'sbuildNonInteractiveSpecfor CLI argument construction (no--ask-for-approval)runner.ts(same timeout/cancel/signal behavior)Wire the adapter into both callsites:
loadWorkforcePersonaModule→ loads the local adapter instead of dynamically importing@agentworkforce/harness-kitricky-local-persona-resolver'sdefaultLoadRunnableSelectionModule→ sameReplace
@agentworkforce/harness-kitwith@agentworkforce/persona-kitinpackage.json.Verification
npm run typecheck→ cleannpm test→ 1379/1379 pass🤖 Generated with Claude Code