Skip to content

feat(framework): Phase 2 PR 4 — approval workflow canonization (closes #67)#76

Merged
montfort merged 1 commit intomainfrom
feat/phase2-pr4-approval-workflow
May 3, 2026
Merged

feat(framework): Phase 2 PR 4 — approval workflow canonization (closes #67)#76
montfort merged 1 commit intomainfrom
feat/phase2-pr4-approval-workflow

Conversation

@montfort
Copy link
Copy Markdown
Contributor

@montfort montfort commented May 3, 2026

Summary

Fourth of 8 PRs implementing Phase 2. Canonizes the human-approval signal that issue #67 identified as a gap. Validated empirically in Sentinel (2 AIDECs applied the same shape locally as "Opción B" before this canonization).

What's added

3 optional frontmatter fields in all 11 templates that need formal approval (AIDEC, ETH, MCARD, ADR, DPIA, INC, SEC + China: PIPIA, CACFILE, TC260RA, AILABEL) across EN, ES, and zh-CN — 33 template files total:

reviewed_by: <reviewer-id>     # email | github-handle | DID
reviewed_at: YYYY-MM-DD
review_outcome: approved       # approved | revisions_requested | rejected

Ship as commented YAML so existing documents continue to validate without modification.

Semantics:

  • The presence of review_outcome is the canonical "human has reviewed" signal.
  • review_required: true is NOT toggled to false after approval — it remains as historical record of why review was needed.
  • reviewed_at must be >= created (will be enforced by devtrail validate in PR 6).

DOCUMENTATION-POLICY.md (EN + ES + zh-CN):

  • §2 Optional Fields extended with the 3 new fields.
  • New §3.5 "Recording Approval" section explaining closure semantics, body section format (compatible with existing ## Approval tables in 7 templates), multi-reviewer convention for v1 (chronological body blocks; structured array deferred), and the CLI tooling on the way.

What's NOT in this PR

  • No CLI code — this is templates + docs only. The devtrail approve command lands in PR 5, and devtrail validate --check-pending-reviews in PR 6.
  • The 7 templates with existing ## Approval table sections (ETH, MCARD, SEC, PIPIA, CACFILE, TC260RA, AILABEL) keep their tables — both forms are documented as canonical, with the frontmatter fields as the machine-readable source of truth.
  • Multi-reviewer structured review: array form — explicitly deferred until at least one adopter exercises a real multi-reviewer flow.

Test plan

  • 33 templates received the same 3-field block in EN, ES, zh-CN (one Python-driven insertion script, idempotent).
  • Existing documents validate unchanged — the new fields are commented out by default.
  • 356/356 tests pass (no CLI code touched, but template loading exercised by integration tests).
  • Manual smoke: read a few templates to verify the YAML comment block is well-formed.

Closes #67.

🤖 Generated with Claude Code

…#67)

Canonizes the human-approval signal for documents whose `review_required:
true` previously had no closure mechanism. Implementation of issue #67
(RFC: Canonical approval workflow), validated empirically in Sentinel
where the same shape was applied locally to 2 AIDECs as "Opción B".

Adds 3 optional frontmatter fields to all 11 templates that need formal
approval (AIDEC, ETH, MCARD, ADR, DPIA, INC, SEC + 4 China variants:
PIPIA, CACFILE, TC260RA, AILABEL) across EN, ES, and zh-CN — 33 template
files total:

  reviewed_by: <reviewer-id>     # email | github-handle | DID
  reviewed_at: YYYY-MM-DD
  review_outcome: approved | revisions_requested | rejected

Fields ship as commented YAML so existing documents continue to validate.
The presence of `review_outcome` is the canonical "human has reviewed"
signal; `review_required: true` remains as historical record after
approval (it's not toggled to false).

DOCUMENTATION-POLICY.md (3 langs) gets:
- §2 Optional Fields extended with the 3 new fields.
- New §3.5 "Recording Approval" section explaining closure semantics,
  the canonical body section format (compatible with existing ##
  Approval tables in 7 templates), the multi-reviewer convention for
  v1 (chronological body blocks; structured array deferred), and the
  CLI tooling on the way (`devtrail approve`, `devtrail validate
  --check-pending-reviews` in PRs 5-6).

This PR is templates + docs only — no code. The CLI commands that
populate these fields atomically land in PRs 5 and 6.

356/356 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closes #67
@montfort montfort merged commit 69c39d0 into main May 3, 2026
@montfort montfort deleted the feat/phase2-pr4-approval-workflow branch May 3, 2026 01:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RFC: Canonical approval workflow for review_required documents (AIDEC, ETH, MCARD, ADR)

1 participant