Parent
docs/issues/unic-archon-dlc/PRD.md
What to build
Post-merge cleanup that catches drift, locks in architectural decisions, and refreshes project state. Ends by reusing the triage workflow from slice 03.
In scope:
/unic-dlc-cleanup <slug> command and .archon/workflows/cleanup.yaml.
arch-review node:
- Reads both
docs/workflow/<slug>/PRD.md (intent) and docs/workflow/<slug>/report.md (technical outcome) alongside the changed code.
- Catches technical drift (modules that became too shallow, tight coupling, leaky abstractions) and intent drift (delivered behaviour diverges from the PRD).
- Proposes deepening opportunities for modules that grew thin during implementation.
- Writes
docs/workflow/<slug>/arch-review.md.
adr-consolidation interactive node:
- Reviews decisions logged during
build (the "Decisions made during implementation" section of report.md) plus any ADR drafts proposed during arch-review.
- Per-ADR approval gate: each proposed ADR is presented individually for accept / reject / edit. Only accepted ADRs are written to
docs/adr/.
- Final node reuses slice 03's
triage workflow — the same .archon/workflows/triage.yaml is referenced via Archon's workflow-include mechanism. Both invocations (standalone vs as cleanup's final node) produce the same HANDOFF.md and the same ROADMAP.md update.
Out of scope: changes to triage itself (any new behaviour belongs in slice 03's file).
Acceptance criteria
Blocked by
PRD: docs/issues/unic-archon-dlc/PRD.md
Migrated from: docs/issues/unic-archon-dlc/13-cleanup-workflow.md (source removed after migration)
Touched by PRs: #33
Parent
docs/issues/unic-archon-dlc/PRD.mdWhat to build
Post-merge cleanup that catches drift, locks in architectural decisions, and refreshes project state. Ends by reusing the triage workflow from slice 03.
In scope:
/unic-dlc-cleanup <slug>command and.archon/workflows/cleanup.yaml.arch-reviewnode:docs/workflow/<slug>/PRD.md(intent) anddocs/workflow/<slug>/report.md(technical outcome) alongside the changed code.docs/workflow/<slug>/arch-review.md.adr-consolidationinteractive node:build(the "Decisions made during implementation" section ofreport.md) plus any ADR drafts proposed duringarch-review.docs/adr/.triageworkflow — the same.archon/workflows/triage.yamlis referenced via Archon's workflow-include mechanism. Both invocations (standalone vs as cleanup's final node) produce the sameHANDOFF.mdand the sameROADMAP.mdupdate.Out of scope: changes to
triageitself (any new behaviour belongs in slice 03's file).Acceptance criteria
/unic-dlc-cleanup <slug>writesdocs/workflow/<slug>/arch-review.mdcovering technical drift, intent drift, and at least one deepening opportunity (or "none identified").adr-consolidationpresents each proposed ADR individually; reject/accept choices are recorded; only accepted ADRs land indocs/adr/..archon/workflows/triage.yaml(no duplicate triage logic);HANDOFF.mdis produced exactly once per cleanup run.docs/workflow/ROADMAP.mdwhen invoked as cleanup's final node (no duplicate ROADMAP logic in cleanup itself).unic-dlc-prefix.Blocked by
PRD:
docs/issues/unic-archon-dlc/PRD.mdMigrated from:
docs/issues/unic-archon-dlc/13-cleanup-workflow.md(source removed after migration)Touched by PRs: #33