unic / unic/unic-agents-plugins

bug(unic-archon-dlc): three /qa nodes emit prose that nothing reads and nothing keeps

Open
#458 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app:unic-archon-dlc bug needs-specs p2
Dominant language
JavaScript
Stars
1
Forks
0
Avg merge
16h 43m
Merged PRs (30d)
19

Description

What happened

Three nodes in /qa emit prose as structured output that nothing reads and nothing writes to disk. The content exists in Archon's SQLite event row and nowhere else. When /cleanup prunes the worktree, it is gone.

Field Emitted at Read by Can write a file?
e2e.summary unic-dlc-qa.yaml:113 nothing No — allowed_tools: [Read, Bash] at :96
coverage-gate.summary :146 nothing No — allowed_tools: [Read, Bash] at :126
uat-prep.criteria :186 nothing

The only $e2e|$coverage-gate|$uat-prep.output.* reference in the whole file is line 337, which reads .result on the first two. summary and criteria have no reader at all.

uat-prep's own prompt states the purpose the emission fails to serve, at :181:

Emit the numbered criteria as structured output so the finding-capture step can reference them

The finding-capture step is uat-gate.on_reject. It references $REJECTION_REASON and nothing else.

Why it matters

uat-gate is the one place in /qa where a human judges the run. Its approval message, :216, tells that human:

review the UAT checklist printed by uat-prep above against the e2e and coverage-gate results

"Above" is console scrollback. So the evidence at the only human gate in this Box is terminal output, and /qa has no report node, so nothing it produces survives the worktree. A reviewer on the pull request sees none of it.

How this was found, and what it is not

It came out of #438's grilling. That ticket claimed /build's implement-review-precheck recorded its findings nowhere. That claim is falseunic-dlc-build.yaml:578 has the report node fold $implement-review-precheck.output.findings in verbatim, and run 2's thirteen findings are committed in workflows/profile-card/report.md § 4 on origin/feature/43004_build-profile-card in DXP-DesignSystem (commit c66eac9).

Surveying the other three Boxes for the same shape is what found these three fields. /build routes its prose correctly. /qa does not.

One observation seeded #438's false conclusion, and it applies here too. "The run's artifacts directory was empty" was true of $ARTIFACTS_DIR, which resolves outside the repo under ~/.archon/workspaces/<name>/artifacts/, is always gitignored, and is reused on resume. The repo-relative Session dir, <artifacts_dir>/<slug>/, is a different place and is deliberately committed. Name the home in every criterion that names a path. A criterion saying "the node writes its summary to the artifacts directory" is satisfiable in a way that fixes nothing.

The pattern that already works here

unic-dlc-pr-review.yaml solves the same problem without a DAG edge: prep writes SESSION/prep.json, and reconcile reads it back at :395. That is why prep's has_source / has_tests / has_types / has_docs / touches_error_handling / prior_findings fields look orphaned to a grep for $prep.output.* and are not. Write the file, read the file.

The open question, to be grilled before criteria

Does /qa gain a durable artefact of its own, or does each node write its own file into <artifacts_dir>/<slug>/?

Neither is decided. The first mirrors /build's report node and gives the human at uat-gate one thing to open; the second is smaller and matches what pr-review already does. A prior question sits under both, the same one #438 turned on: who is the reader, and when do they read? The human at uat-gate during the run, and the reviewer on the pull request afterwards, pull in different directions.

Overlap to state in whatever criteria this gets

#430's criterion 10 was amended on 2026-09-03 to require its unresolved-needs block to be durable, in a file under <artifacts_dir>/<slug>/. In /qa that block attaches to exactly the two summaries above. So #430 and this ticket touch the same file and the same nodes, and #430 is the one dispatched. Whichever lands first, the other rebases. If #430 lands first it will have created a file-writing surface in /qa that this ticket then generalises, which is the cheaper order.

Out of scope for run 3

Ruled by the maintainer on 2026-09-03: /qa is not needed for run 3 or for the #456 map. This ticket carries the /qa half so #438 can keep only its /build half.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with unic-dlc-qa.yaml at the listed node and prompt lines, then compare unic-dlc-pr-review.yaml's prep/reconcile file flow and /build's report node. Before implementation, resolve whether /qa has one durable artifact or per-node files, identify readers at uat-gate and pull-request review, and coordinate with dispatched #430; done means the selected design preserves the named evidence for both readers.

Written by the indexing model from the issue text.

Assessment

Tech stack
yaml
Domain
tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.