fix(decisions-log): enumerate decisions.yaml writes in every phase agent (closes #399)#400
Merged
Conversation
…ent (closes #399) Phase 2-9 agents never wrote decisions.yaml rows because the procedural authority (per-step `Output:` bullets in `agents/<phase>.md`) was silent on them, even though 8 downstream skills carried well-formed Decisions Log catalogs in their SKILL.md. Phase 1 had the canonical pattern but PR #4 of the decisions-log series shipped only the catalogs, not the agent-file enumeration. Result: 22+ completed steps across 6 phases on malaria-itn-app run 20260521-1400 produced zero decision rows. Mirror Phase 1's pattern in every downstream phase. Each Step that maps to a Decisions-Log-carrying skill now enumerates the anchor row IDs: - commcare-setup Step 1 (pdd-to-deliver-app): deliver-unit-count, one-form-per-module-workaround, multimedia-coverage-strategy - commcare-setup Step 2.6 (app-test-cases): test-scenario-count, test-archetype-coverage - connect-setup Step 2 (connect-opp-setup): verification-flags, payment-unit-shape, opportunity-end-date - ocs-setup Step 1 (ocs-agent-setup): system-prompt-baseline, rag-collection-scope, test-prompt-count - synthetic-data-and-workflows Step 1 (synthetic-narrative-plan): persona-count, scenario-count, narrative-arc-shape - solicitation-management Step 1 (solicitation-create): solicitation-type, response-deadline, response-template-choice - execution-manager Step 3 (llo-launch): llo-capacity-actual, day-one-readiness, downstream-handoff-alignment, stop-loss-planning - closeout Step 1 (opp-closeout): closeout-depth, learnings-summary-scope orchestrator-reference.md § Phase Write-Back Contract § Decisions log clause now explicitly names the per-step agent-file Output block as the load-bearing procedural authority — the SKILL.md catalog is a teaching device, not a checklist — so adding a new anchor-row skill in future requires updating BOTH locations. Out of scope (called out for follow-up): - `app-test-cases/SKILL.md` records its rows with `phase: 6-qa-and-training` even though dispatch happens in Phase 3. Phase mismatch noted inline in commcare-setup.md. - Suggested guardrail (downgrade phase verdict when a phase with an anchor catalog writes zero rows) — separate change; the per-step enumeration is the proximate fix. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jjackson
added a commit
that referenced
this pull request
May 22, 2026
… 6-qa-and-training) `app-test-cases/SKILL.md` recorded its decisions-log rows with `phase: 6-qa-and-training` even though the skill is dispatched from `agents/commcare-setup.md § Step 2.6` (Phase 3). The convention used by every other writer skill is "the phase the skill is dispatched in," and the artifact manifest already maps the producer's output to `3-commcare/app-test-cases.yaml` (see `lib/artifact-manifest.ts:383`). The `6-qa-and-training` tag was a mismatch — rows would group under the wrong phase in the rendered decisions.gdoc and confuse the Phase Write-Back Verifier's per-phase row-count checks (when those land). No data migration needed — issue #399 surfaced that this skill had written zero rows in practice (the bug it documented), so there's no historical decisions.yaml content tagged with the old phase. Flagged inline in commcare-setup.md by PR #400 as a follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
2 tasks
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.
Summary
Closes #399.
Phase 2-9 agents were never writing rows to
decisions.yamlbecause the procedural authority — the per-stepOutput:bullets inagents/<phase>.md— was silent on it, even though 8 downstream skills already carried well-formed Decisions Log catalogs in theirSKILL.md. Phase 1 had the canonical pattern; PR #4 of the decisions-log series shipped the catalogs without the matching agent-file enumeration. Result onmalaria-itn-apprun20260521-1400: 22+ completed steps across 6 phases produced zero decision rows.What changed
Appended verification-flags, payment-unit-shape, opportunity-end-date rows in decisions.yaml).agents/orchestrator-reference.md § Phase Write-Back Contract § Decisions log clauseto explicitly name the per-stepOutputbullet as the load-bearing procedural authority. The## Decisions Logsection in the writing skill'sSKILL.mdis a teaching device; the agent file is what the dispatched subagent treats as its checklist. Future skills adding anchor rows must update both.Out of scope (follow-ups)
app-test-cases/SKILL.mdrecords its rows withphase: 6-qa-and-trainingbut is dispatched in Phase 3 (commcare-setupStep 2.6). Noted inline; needs a separate fix to either align the SKILL.mdphase:field or move dispatch.Test plan
/ace:run(any opp) produces non-zerodecisions.yamlrows from Phase 3-10 skills.decisions.gdocrendered bydecisions-rendershows rows under all phases that ran, not just Phase 1.🤖 Generated with Claude Code