Generalize phase 4 (code→build) and phase 5 (docs→document): verification chosen by the artifact, not always tests

[luisherranz]

Goal

Radical Pipelines stops assuming the product is always executable code and documentation is a derivative of it. Phase 4 generalizes from "code" to "build" — realize the primary artifact the issue ships, whatever its format (code, prose-product like a skill or a guide, a brand-new docs page) — with the verification chosen by the nature of the artifact and the change (a new test, command gates, or a judgment check), not always tests. Phase 5 generalizes from "docs" to "document" — describe the realized product for its audience, reactively. The phases and their agents are renamed to match.

Constraints

• Additive generalization, not a rewrite. The normal case (software verified by tests, with derived docs) must not change behavior: tdd/e2e, build=code, document=reactive docs keep working exactly as today. It must not break base runs, existing intent/pr-review revisions, the per-phase completion predicates, or any pipeline already on disk.
• Depends on Make guardrails prose #151 (guardrails as prose). The prose verification this issue needs in build rides on the command / judgment guardrails that Make guardrails prose #151 introduces. This issue assumes that work is done.
• Mind the rename blast-radius. Renaming 4-code/→4-build/, 5-docs/→5-document/, the agents, the *-summary.md files, the completion predicates in pipeline-versioning.md, the conventions, and reconciling pipelines already on disk touches many places. The rename is a sub-axis to settle deliberately, in a way that does not break existing pipelines (migration vs. alias vs. new-pipelines-only — a spec/design decision).
• Specialization over polymorphism. The build writers are specialized per discipline (not one polymorphic agent that switches modes). Reviewers stay uniform (one per phase).

Context

• This surfaced running BILLOW-78 as a pr-review revision (see Add a pr-review origin for revision runs (per-comment ledger + pr-review-responses.md) #163). Two gaps showed up: phase 4 has no writer for a change with no behavior to test, and prose-as-the-product / prose-as-the-goal does not fit the code/docs split.
• The assumption that breaks: the pipeline implicitly treats the product = code and documentation = a derivative of code. That holds for software-with-derived-docs, but breaks on two independent axes: a verification axis (code changes with no behavior to test — prose-in-code, deletions, type-only, config) and an artifact axis (the primary artifact is not code at all — a guide, a skill).
• The project already practices this on itself. From Make guardrails prose #151: "the skill is prose, not software; do not write structural tests over skill/agent files. Verification is by reading." Radical Pipelines already treats its own product as prose verified by reading/judgment — this issue generalizes a practice the project already lives, it does not invent one.
• Where each example lands (the core of this issue):

Case	Primary artifact	Phase 4 (build) does	Verification	Phase 5 (document) does
Normal (software, behavior change)	code	write code + test	new test + gates	reactive docs of the change
BILLOW-78 (review, no-test edits)	code	apply edits (mix tdd/edit)	command gates	reference .md docs + pr-review-responses.md
New guide — #67, docs is the goal	the guide	write the guide	md-lint + link-check + accuracy + adversarial review	minimal: index/nav/changelog (or empty)
Skill / radical-pipelines — product is prose	the skill's .md files	edit the skill files	md-lint + coherence + non-contradiction + adversarial review	skill README/CONTRIBUTING/changelog

• The phase is decided by the artifact's role in this issue, not by its type. The same docs-site is build when an issue creates it as the goal (e.g. Docs site #67's first generation) and document when a later pipeline updates it reactively after the product changed. So "do docs go in 4 or 5?" resolves by role (product-being-produced vs. product-being-described), with no by-extension rules.

Assumptions / directions to explore

Open hypotheses for the spec/design phases to confirm or revise, except where noted.

The reframe (product vs. description)

• Phase 4 = build — produce and verify the primary artifact the issue ships, regardless of format.
• Phase 5 = document — describe that product for an audience; reactive to phase 4. It may legitimately be minimal or empty (ties into right-sizing).

Verification strategy generalized (the Type field)

Type moves from "test strategy" to "verification strategy", a complete taxonomy that routes each task to a writer:

• tdd — code with a behavior change, proven by a new unit test.
• e2e — code with a behavior change, proven by a new e2e test.
• edit — a code change with no behavior to test (prose-in-code/docblocks, deletions, type-only, config, mechanical refactor); correctness established by command gates (lint/typecheck/existing suite green).
• prose — a prose-product artifact (skill, guide, docs-as-goal); verified by command + judgment guardrails (md-lint, link-check, coherence, accuracy-against-source, adversarial review).

Guard against edit/prose becoming a test-dodging escape hatch: the plan reviewer validates the Type choice ("is there genuinely no behavior to test here?") and the build reviewer confirms no untested behavior shipped. Type is a reviewed claim, not a self-grant.

Agents (specialized, renamed)

Keep the <phase>-<role> pattern; put specialization in the build writers, by discipline:

• Phase 3 (plan): build-plan-writer / build-plan-reviewer (was code-plan-*); document-plan-writer / document-plan-reviewer (was docs-plan-*).
• Phase 4 (build): build-writer-tdd, build-writer-e2e (existing, renamed), plus new build-writer-edit (no-test code) and build-writer-prose (prose-product); one build-reviewer (was code-reviewer).
• Phase 5 (document): document-writer, document-reviewer (was docs-*).

Two rules to keep specialization bounded:

1. A new writer only when its discipline is genuinely different, not per artifact type. tdd ≠ e2e ≠ edit ≠ prose are four distinct ways of working → four writers; the task's Type routes to one (as tdd/e2e already route to two today).
2. Specialization lives in the writers, not the reviewers. A reviewer's job (check against plan/spec/design + run each task's guardrails — already per-task thanks to Make guardrails prose #151) is uniform, so one build-reviewer and one document-reviewer suffice.

build-writer-prose and document-writer use the same prose-writing technique but are distinct roles (produce the goal artifact vs. describe the product), with different inputs and purpose — keep them separate; share common writing guidance via prompt include, not by merging agents.

Rename surfaces (the sub-axis)

4-code/→4-build/; 5-docs/→5-document/; the agents above; code-summary.md/docs-summary.md→build-summary.md/document-summary.md; the completion-predicate table in pipeline-versioning.md; the conventions (.rp.md model table, etc.). Do the rename together with the semantic change (so the old names don't perpetuate the broken assumption), but only after the build/document boundary question below is settled.

Open questions for spec/design

• When the product is prose, is the build/document boundary still crisp or does it sometimes collapse? (Skill: crisp — the skill is build, its README is document. Docs site #67: document nearly vanishes.) The final naming depends on this.
• Rename without breaking pipelines already on disk (existing 4-code/): migration, alias, or new-pipelines-only?
• Final names for the Type values (edit vs none vs plain; prose).
• How is the primary artifact classified (code vs. prose-product vs. docs-as-goal) — declared in the intent, derived in spec, or a phase decision? (Leans on the typed ledger / right-sizing item classification.)
• Does phase 3 (plan) need changes beyond the rename to route tasks to the new writers/artifacts?
• Exact prose guardrail set, and how much is shared between a build-writer-prose task and a document-writer task.

[luisherranz]

Partially resolved by #181: the code→build / docs→document rename, the plan folding, and the role-based (product vs. description) framing shipped with architecture v2. Still open here: the verification axis — verification chosen by the artifact (judgment checks, an edit-style type for no-test changes) — which depends on the guardrails-as-prose work (#150).