review-implementation-architecture
Use this skill to review a completed or in-progress implementation for an architecture-level simplification task generated by the reduce-architectural-complexity workflow.
This skill reviews the actual implemented change, not the pre-implementation task design. It is distinct from review-task-architecture, which judges whether a Munera task design fits the project architecture before implementation.
Required orientation
- Read the Munera task artifacts at the provided task path:
design.md
plan.md when present
steps.md
implementation.md
- Read the selected target and evidence from task-local, worktree-root-relative files. Do not assume workflow context inlines these artifact contents:
architecture-targets.edn
target-issues.edn when present, otherwise target-issues-unavailable.edn
before-diagnose.edn
after-diagnose.edn
after-architecture-targets.edn
architecture-compare.edn
architecture-gate.edn
characterization-baseline.edn when present
- Read the project architecture sources relevant to the touched area:
AGENTS.md
ramora/META.md
doc/architecture.md
- any local architecture docs referenced by the task or touched namespaces
- Inspect the implementation diff and the affected code/tests/docs. Prefer runtime/test evidence over prose claims.
Judgement criteria
Flag actionable feedback when any criterion below is not satisfied.
Behaviour preservation
- The change preserves externally visible behaviour named in the generated task.
- Characterization and affected-area tests cover the behaviour the architecture refactor could disturb.
- Validation failures, missing artifacts, or unreadable Gordian artifacts are not accepted silently.
Target fit
- The implementation addresses the selected
architecture-targets candidate recorded in the task.
- If
target-issues.edn is present, the implementation engages the observations, hypotheses, refactoring directions, review questions, and success signals without treating hypotheses as facts.
- If only
target-issues-unavailable.edn is present, the implementation is still justified by architecture-targets.edn, before/after Gordian evidence, and project architecture sources.
- The review does not switch to a different target because a more interesting issue appears nearby.
Blast-radius discipline
- Production edits stay within
:target/source-areas plus explicitly recorded :target/allowed-adjacent-source-areas.
- Adjacent-source edits have a task-local reason recorded before or during implementation.
- External namespaces mentioned by evidence are treated as review context, not implicit membership.
- Test edits stay tied to
:target/affected-test-areas or newly recorded affected tests.
Architectural improvement / no regression
- The implementation improves or credibly reduces the selected architecture problem without introducing worse coupling, cycles, ownership blur, unstable shared dependencies, or hidden coordination.
architecture-compare.edn, architecture-gate.edn, and after-architecture-targets.edn support the claimed outcome, or any non-moving metric is explicitly and plausibly explained for this slice.
- The change follows project boundaries: dispatch owns state mutation, resolvers own reads, effects stay at effect/runtime boundaries, adapters remain projections/entry points, and extensions remain isolated.
Simplicity and shape
- The change reduces architectural complexity rather than adding compatibility shims, adapters, broad indirection, or parallel models.
- New abstractions have one obvious owner and are locally comprehensible.
- Existing patterns are reused when they fit; new patterns are introduced only when the task evidence justifies them.
Output contract when used via review-step
Append a terse note to the task's implementation.md. Add unchecked follow-up items to steps.md for every new actionable issue. Avoid duplicating existing notes or follow-ups. End with exactly one of:
PASS_STATUS: ACTIONABLE_FEEDBACK
PASS_STATUS: REVIEW_COMPLETE
1---2name: review-implementation-architecture3description: Review an implemented architecture-level simplification against the selected Gordian target, validation evidence, project architecture, and blast-radius constraints.4---56# review-implementation-architecture78Use this skill to review a completed or in-progress implementation for an architecture-level simplification task generated by the `reduce-architectural-complexity` workflow.910This skill reviews the **actual implemented change**, not the pre-implementation task design. It is distinct from `review-task-architecture`, which judges whether a Munera task design fits the project architecture before implementation.1112## Required orientation13141. Read the Munera task artifacts at the provided task path:15 - `design.md`16 - `plan.md` when present17 - `steps.md`18 - `implementation.md`192. Read the selected target and evidence from task-local, worktree-root-relative files. Do not assume workflow context inlines these artifact contents:20 - `architecture-targets.edn`21 - `target-issues.edn` when present, otherwise `target-issues-unavailable.edn`22 - `before-diagnose.edn`23 - `after-diagnose.edn`24 - `after-architecture-targets.edn`25 - `architecture-compare.edn`26 - `architecture-gate.edn`27 - `characterization-baseline.edn` when present283. Read the project architecture sources relevant to the touched area:29 - `AGENTS.md`30 - `ramora/META.md`31 - `doc/architecture.md`32 - any local architecture docs referenced by the task or touched namespaces334. Inspect the implementation diff and the affected code/tests/docs. Prefer runtime/test evidence over prose claims.3435## Judgement criteria3637Flag actionable feedback when any criterion below is not satisfied.3839### Behaviour preservation4041- The change preserves externally visible behaviour named in the generated task.42- Characterization and affected-area tests cover the behaviour the architecture refactor could disturb.43- Validation failures, missing artifacts, or unreadable Gordian artifacts are not accepted silently.4445### Target fit4647- The implementation addresses the selected `architecture-targets` candidate recorded in the task.48- If `target-issues.edn` is present, the implementation engages the observations, hypotheses, refactoring directions, review questions, and success signals without treating hypotheses as facts.49- If only `target-issues-unavailable.edn` is present, the implementation is still justified by `architecture-targets.edn`, before/after Gordian evidence, and project architecture sources.50- The review does not switch to a different target because a more interesting issue appears nearby.5152### Blast-radius discipline5354- Production edits stay within `:target/source-areas` plus explicitly recorded `:target/allowed-adjacent-source-areas`.55- Adjacent-source edits have a task-local reason recorded before or during implementation.56- External namespaces mentioned by evidence are treated as review context, not implicit membership.57- Test edits stay tied to `:target/affected-test-areas` or newly recorded affected tests.5859### Architectural improvement / no regression6061- The implementation improves or credibly reduces the selected architecture problem without introducing worse coupling, cycles, ownership blur, unstable shared dependencies, or hidden coordination.62- `architecture-compare.edn`, `architecture-gate.edn`, and `after-architecture-targets.edn` support the claimed outcome, or any non-moving metric is explicitly and plausibly explained for this slice.63- The change follows project boundaries: dispatch owns state mutation, resolvers own reads, effects stay at effect/runtime boundaries, adapters remain projections/entry points, and extensions remain isolated.6465### Simplicity and shape6667- The change reduces architectural complexity rather than adding compatibility shims, adapters, broad indirection, or parallel models.68- New abstractions have one obvious owner and are locally comprehensible.69- Existing patterns are reused when they fit; new patterns are introduced only when the task evidence justifies them.7071## Output contract when used via `review-step`7273Append a terse note to the task's `implementation.md`. Add unchecked follow-up items to `steps.md` for every new actionable issue. Avoid duplicating existing notes or follow-ups. End with exactly one of:7475`PASS_STATUS: ACTIONABLE_FEEDBACK`7677`PASS_STATUS: REVIEW_COMPLETE`