docs: public-disclosure boundary for changelog fragments and evidence snapshots - #121
Conversation
Public changelog fragments and future status snapshots record user-visible effect at coarse resolution; private-runtime implementation strategy and ops detail stay in the private producer's records. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c7cc17b990
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Fragments compile into the public `CHANGELOG.md`, the GitHub release notes, | ||
| and permanent git history. They are among the most widely read prose this |
There was a problem hiding this comment.
Stop claiming fragments compile into GitHub release notes
The release pipeline does not compile fragment content into the GitHub release notes: the Create GitHub Release step in .github/workflows/release.yml lines 202–216 supplies a fixed policy-only or activation summary via gh release create --notes "$NOTES" and merely directs readers to CHANGELOG.md. Describing the notes as a direct publication surface misstates where fragment text is exposed and could lead maintainers to reason incorrectly about release-note generation; distinguish the compiled changelog from the separately authored GitHub release body.
Useful? React with 👍 / 👎.
Outcome
Executes R2 and R3 from the 2026-08-18 operator-directed distillation review of the public architecture corpus. Root finding: private-runtime implementation vocabulary reached public prose through release-time changelog fragments (compiled into
CHANGELOG.md, release notes, and permanent history), not through the handbook, so the control point is fragment authoring, forward-only.changelog.d/README.mdgains a "Public-disclosure boundary for fragment content" section (user-visible effect and contract changes at coarse resolution; mechanism names, internal lifecycle steps, fallback-ladder designs, host fleets, and route counts stay in the private producer's records; reviewers treat a crossing fragment as a change request). The release-closeout layering paragraph indocs/architecture/repository-and-release.mdnow names fragments and release notes as bound by the same boundary.docs/architecture/status-and-evidence.md"Updating the snapshot" gains a coarse-operational-detail rule for future snapshots; existing snapshot rows are explicitly recorded history and unchanged.No generated history, signed release, or existing snapshot content is rewritten; no executable, policy-module, packaging, or release-flow change. A separately governed private workspace companion lands in the same cycle.
author: claude
standing_directives: Step 0 intent check MATCH; forward-only rule, no history rewrite; public-docs sanitization contract followed
tier: 1
cross_check: N/A (Tier 1 documentation/authoring-guidance change; no executable or release-flow effect)
post_condition: docs-only; merge only on green CI
mcp_coverage_gap: not applicable (no MCP surface touched); gemini_mcp_path: retired / not applicable
operator_reserved: no (operator directed this change: "Execute R2 and R3", 2026-08-18)
contributor_rights: OWNER-AUTHORED
plugin_affected: docs and authoring guidance only; no packaged content change; no version bump or release
readme_refresh_status: not a plugin release; repo README unaffected