[Governance] make GitHub Issues the traceable requirements source of truth

[PeterGuy326]

schemaVersion: requirement-record.v1
revision: R1
status: ready
productOwner: "@PeterGuy326"
technicalOwner: "unassigned"
userOutcome: "Contributors can determine the current approved requirement, why it changed, and which immutable evidence proves delivery from one GitHub Issue trace."
requirements:
  - REQ-001
  - REQ-002
  - REQ-003
  - REQ-004
  - REQ-005
  - REQ-006
acceptanceCriteria:
  - AC-001
  - AC-002
  - AC-003
  - AC-004
  - AC-005
  - AC-006
parent: null
dependencies: []
supersedes: []
lastDecisionAt: "2026-08-05T07:52:53Z"

用户问题

Contributors and maintainers can record a problem and checklist today, but they cannot reliably
reconstruct one current, approved requirement across an Issue, later product decisions, a PR,
commits, tests, and closure evidence. The organization defaults do not require stable REQ/AC IDs,
an Issue revision, an acyclic cross-repository dependency graph, superseding decision history, or a
verification ledger.

This creates three observable failures:

• an edited body can erase why scope or acceptance changed;
• a green PR or local commit can be mistaken for an accepted user outcome without current-revision
  evidence;
• repository documents, local drafts, and implementation status can compete with GitHub Issues as
  informal requirement records.

产品决策

Adopt GitHub Issues as the requirements source of truth for ByteFolk. The current Issue
body will hold the effective requirement revision; immutable superseding decision comments will
hold semantic change history; immutable verification-ledger comments will bind the current revision
to merged PRs, full commit SHAs, AC-linked tests, and product acceptance.

The Canonical executable governance contract in this Issue body is the complete normative
minimum. Publish it as stable organization policy at REQUIREMENTS.md in this public .github
repository. That document is a reviewed mirror for contributors, not a competing requirement
record; every normative difference requires a semantic Issue revision first.

Provide organization defaults and read-only linting that make the policy executable. Migrate open
Issues non-destructively through an inventory and per-Issue/per-repository approvals; do not bulk
rewrite history. Once persisted, ready product-authorizes implementation of the frozen scope;
live Issue edits, new labels, branch protection, push, PR, merge and rollout remain separately
guarded GitHub mutations.

Issue Forms remain input collectors. At triage, a maintainer/product owner converts those inputs
into the exact shared requirement-record:v1 body, resolves product fields, and runs lint. Only a
normalized body that passes lint may receive status:ready; create-time form text is never treated
as generated REQ/AC authority.

范围

• Add stable REQUIREMENTS.md policy to the .github repository and link it from GOVERNANCE.md
  and CONTRIBUTING.md.
• Provide a shared requirement template and normalization-at-triage guide covering the machine
  index, user problem, product decision, scope/non-goals, REQ-ID, dependency DAG, AC-ID, status,
  evidence, and change history; existing Issue Forms remain input-only.
• Extend deterministic governance validation with requirement-record:v1, trace, document-boundary,
  sensitive-data, and mutation-contract checks; validation remains read-only.
• Update PR guidance and define commit trailers, AC-linked test mapping, superseding decision,
  verification-ledger, and closure records.
• Inventory all open organization Issues and give each a visible migration disposition and owner;
  normalize live Issues only through separately approved mutations.
• Add fixtures and documentation proving the lifecycle from needs-design through ready and
  current-revision evidence to explicit done closure.

非目标

• Do not modify, absorb, close, relabel, or reinterpret .github#6 or .github#7 in this Issue.
• Do not define or change any product North Star, product route, runtime architecture, module
  boundary, feature priority, or repository-specific functional requirement.
• Do not automatically edit historical Issues, comments, labels, states, PRs, commits, tests,
  rulesets, or branch protection.
• Do not require rewriting closed Issue history; follow-up work links to it without mutating it.
• Do not treat a local Markdown file, chat, Project view, PR body, branch, or unpushed commit as the
  canonical requirement record.
• Do not implement an auto-fix bot. Lint reports violations and stable machine codes but never
  creates, edits, comments on, labels, closes, or reopens an Issue.
• Do not publish private repository/Issue URLs, service topology, credentials, user payloads,
  production logs, personal data, model context, or chain-of-thought.
• Do not treat ready as done, bypass exact GitHub mutation approval, or claim delivery before the
  same-revision PASS-ledger → closure → close/readback sequence completes.

Canonical executable governance contract

This section is the normative requirements-governance minimum owned by this Issue revision. The
future REQUIREMENTS.md, templates, linter and guides MUST mirror it; if they conflict, this Issue
wins. MUST, MUST NOT, SHOULD and MAY are normative keywords.

A. Authority and normalization

1. Every active requirement, product decision, implementation unit, blocker and acceptance
   invariant MUST have exactly one canonical GitHub Issue owner.
2. The current Issue body holds the effective requirement; immutable
   requirement-decision:v1 comments hold superseded semantics; immutable
   verification-ledger:v1 comments hold evidence; requirement-closure:v1 records acceptance.
3. Local files, chat, meeting notes, Project views, repository docs, branches, commits and PRs MAY
   supply input or evidence but MUST NOT replace the owner Issue.
4. Stable repository docs MAY mirror North Star, accepted contracts and governance. They MUST NOT
   carry changing implementation status, blockers or a competing backlog.
5. Issue Forms collect raw input only. They MUST NOT fabricate authoritative REQ/AC IDs or mark a
   record ready at create time.
6. At triage, the maintainer/product owner MUST normalize the exact body with the shared template,
   decide product fields, run read-only lint and only then apply status:ready.
7. ready means the frozen scope is product-authorized for implementation. It does not mean work
   started, evidence passed or the Issue is done, and it never bypasses GitHub mutation approval.

B. Minimum Issue record

The first body block MUST contain exactly one requirement-record:v1 HTML marker (rendered in
guidance as <!-- requirement-record:v1 -->), immediately
followed by this safe-parsed YAML index:

schemaVersion: requirement-record.v1
revision: R1
status: needs-design
productOwner: "@github-handle"
technicalOwner: "unassigned"
userOutcome: "one observable user outcome"
requirements:
  - REQ-001
acceptanceCriteria:
  - AC-001
parent: null
dependencies: []
supersedes: []
lastDecisionAt: "2026-08-05T00:00:00Z"

The body MUST then contain nonempty sections for 用户问题, 产品决策, 范围, 非目标,
Requirements, 依赖 DAG, Acceptance Criteria, 状态与待决项, 证据, and 变更历史.

• User problem states who, scenario, problem and observable loss; an implementation filename is not
  a user problem.
• Product decision states one current solution and why; unresolved alternatives imply
  needs-design.
• Scope names the one outcome/contract owned here; non-goals exclude adjacent work and ownership.
• REQ IDs match REQ-[0-9]{3}, are unique/append-only within the Issue and are fully referenced as
  owner/repo#number/REQ-001.
• AC IDs match AC-[0-9]{3}, are unique/append-only, use Given/When/Then, declare evidence type and
  reference at least one live REQ.
• Every MUST REQ has at least one AC; every AC verifies at least one REQ. IDs are never reused after
  retirement.
• Parent, dependency and supersedes targets use full Issue URLs. A blocking dependency includes a
  stable DEP-ID, blocked_by, target URL and observable exit condition.
• dependencies: [] means there is no blocker, not that dependency discovery is unfinished.

Normalized REQ and AC entries use this exact minimum shape:

### REQ-001 — name
- Statement: observable MUST or MUST NOT behavior
- User value: link to the user problem
- Priority: MUST | SHOULD | MAY
- Owner: 本 Issue

### AC-001 — name
- Verifies: REQ-001
- Given: reproducible precondition
- When: action
- Then: observable pass/fail result including negative behavior
- Evidence required: test | CI | manual | security-review | migration-rehearsal | independent-review | inventory

ready records MUST contain no TBD, unresolved placeholder, uncovered MUST, circular dependency,
unknown owner, ambiguous outcome or unmeasured QPS/SLA promise.

Evidence tokens are exactly test, CI, manual, security-review, migration-rehearsal,
independent-review, and inventory. + means every named evidence type is mandatory. The Issue
evidence section MUST contain an AC→evidence crosswalk identical to each AC declaration; unknown,
missing or extra types fail closed.

C. New Issue, augmentation and ownership

A new Issue is mandatory when any one is true: the user problem/outcome differs; owner, repository,
visibility or security boundary differs; work can release/rollback/accept independently; it creates
a new DAG node; it changes a non-goal; the old Issue is done/closed; or sensitive detail needs a
private advisory/Issue.

The original Issue may be augmented only when user problem, outcome, owner, repository, visibility,
release unit, non-goals and dependency direction remain unchanged and the addition only clarifies
an existing REQ/AC or strengthens evidence. A semantic augmentation still uses the superseding flow.

Each REQ has one owner Issue. Split work keeps the end-to-end outcome in a parent and gives each
child a non-overlapping independently accepted delivery. Replacement uses supersedes; the old
Issue records the replacement and closes not planned, never fake done.

D. Status contract

• needs-design: problem is valid but decision/scope/REQ/AC/dependency/security is unresolved.
  Read-only research is allowed; production implementation/merge/release is not.
• ready: solution, scope/non-goals, all MUST REQ/AC, DAG, safety and compatibility are frozen with
  no unmet blocker. In-scope implementation is product-authorized.
• blocked: product design is complete but an external prerequisite is unmet. It requires
  blocked_by, blocker owner, exit condition and last check. Difficulty, failing tests and “not
  started” are not blockers.
• HOLD: product deliberately forbids production implementation pending a named trigger/review.
  HOLD requires decision owner, reason and resume condition; it is not low-priority ready.
• done: all closing gates passed for the current requirement revision and the Issue is closed with
  GitHub reason completed. not planned, duplicate, superseded and unable-to-reproduce are not
  done.

Body status, available status:* label and GitHub state MUST agree. A repository missing a status
label must track label governance rather than substitute a false label.

E. Requirement revision and event history

Only a semantic change to one of these seven fields increments revision: user problem, product
decision, scope, non-goals, REQ, AC, dependency.

Pure status/label/priority/assignee/milestone transitions, blocker resolution, evidence append,
verification ledger, closure, readback, spelling, link or formatting changes MUST retain the same
requirement revision. They remain auditable events and MUST NOT hide a seven-field semantic change.

For a seven-field semantic change, use this order:

1. guard URL, current revision, updatedAt, raw body SHA, state, labels and comment count;
2. obtain approval for exact decision comment, exact body/diff and all metadata writes;
3. append an immutable requirement-decision:v1 comment;
4. fresh-read and abort on concurrent drift;
5. update the current body, increment revision exactly once, add the Decision-ID/comment link to
   history and synchronize any status metadata;
6. read back exact body/comment/state/labels and re-check every open PR revision.

<!-- requirement-decision:v1 -->
Decision-ID: DEC-003
Supersedes: R2 / DEC-002
Effective revision: R3
Approved-by: @product-owner
Approved-at: <ISO-8601 UTC>
Affected: REQ-002, AC-003, DEP-001

Previous decision:
- ...
New decision:
- ...
Why:
- ...
Impact:
- implementation: continue | stop | rework | none
- compatibility/migration: ...
- resulting status: needs-design | ready | blocked | HOLD | done

Decision comments MUST NOT be edited/deleted. Correct them with a later comment. A pure operational
event uses the current revision and a typed status/ledger/closure comment; it does not create a fake
revision.

F. PR, commit and test trace

Every behavior-changing PR MUST contain:

Requirement-Issue: https://github.com/<owner>/<repo>/issues/<n>
Issue-Revision: R1
Implements: REQ-001
Verifies: AC-001
Non-goals-preserved: yes
Verification-Ledger: pending | <comment URL>

PR scope outside declared REQs or inside non-goals first requires a semantic Issue decision. Use
Refs, not automatic Fixes/Closes; merge, verify and close explicitly. Draft/local/unpushed work
is never completion evidence.

Each behavior commit carries Requirement-Issue, fully qualified Requirement, Acceptance, and
Issue-Revision trailers. Each automated test name contains [AC-001] or has one machine-readable
test→AC mapping. Evidence pins full merged SHA, CI/artifact permalink, environment/version, result,
time and verifier. Security/race/restart/migration ACs require evidence of their own type.

G. Verification ledger and non-circular closure

Append immutable evidence before changing status to done:

<!-- verification-ledger:v1 -->
Ledger-ID: VER-004
Issue-Revision: R1
Commit: <permanent merged commit URL and full SHA>
PR: <merged PR URL>
Verifier: @independent-reviewer
Verified-at: <ISO-8601 UTC>

| AC-ID | Evidence permalink | Environment | Result |
|---|---|---|---|
| AC-001 | ... | ... | PASS |

Exceptions: none
Sensitive-data check: PASS

FAIL evidence remains in history and blocks closure. A new semantic revision invalidates older
revision ledgers for closure; status/evidence changes do not create a revision, so one revision may
have multiple ledgers and only its latest complete PASS ledger closes it.

Closure order is mandatory and non-circular:

1. while Issue is ready/current Rn, persist a complete Rn PASS ledger from merged evidence;
2. append requirement-closure:v1 referencing that ledger and the same Rn;
3. under a fresh exact guard, update body status/label and close completed while retaining Rn;
4. read back body revision/status, label, completed reason, ledger and closure links.

<!-- requirement-closure:v1 -->
Accepted revision: R1
Accepted requirements: REQ-001
Passed acceptance: AC-001
Verification ledger: <comment URL>
Merged delivery: <PR URL> @ <full SHA>
Follow-ups: none | <Issue URLs>
Product acceptance: @owner / <ISO-8601 UTC>
Close reason: completed

A PASS ledger never requires done; done requires the pre-existing PASS ledger. Thus
ready R1 → done stays R1. Partial delivery first uses a semantic scope decision/new revision or
new child Issue, then re-verifies; it cannot close by silently dropping ACs.

H. Cross-repository, visibility and sensitive data

Parents own end-to-end outcome/overall AC; children own one repository/owner delivery. Both sides
link full URLs and input/output contracts. Blocking edges have one direction and the graph MUST be
acyclic. A parent cannot close before required children; an open parent alone does not block a child.

Private Issues may link pinned public contracts. Public Issues MUST NOT expose private repo/Issue
URLs, service URLs, deployment topology, credentials or private evidence; use an approved opaque
dependency reference, with the private mapping kept privately. Cross-repo contracts pin a release,
tag, full SHA or permalink, never “latest main”.

No public or private trace record may contain token/cookie/password/private key/connection-string
values, user/customer payloads, model context, chain-of-thought, production log excerpts, personal
data, unapproved private URLs, host paths or employee emails. Security details live in a private
advisory; public tracking is sanitized. Scanners report rule and PASS/FAIL without printing values.

I. Exact GitHub mutation approval

Create/edit/comment/label/state/assignee/milestone/close/reopen and push/PR/merge are mutations. Before
each approved Issue or exact batch, show target, ordered actions/write count, full title/body/comment
or exact diff, metadata before→after, concurrent guards and sensitive scan. Only explicit approval
naming that Issue/batch authorizes writes.

Approval expires on any updatedAt/body/state/label/comment-count guard drift, payload/action/write-
count change, new target, visibility change or sensitive finding. Execute in order, fresh-read
between writes, stop on mismatch, never silently repair, and report URLs/digests/final state plus
actual GitHub writes=N. Ambiguous create/comment results are read back before retry.

J. Deterministic read-only lint

The linter MUST expose these 24 stable machine codes:

Code	Failure
ISSUE001	schema marker missing or not unique
ISSUE002	YAML missing/unknown keys, invalid status or revision
ISSUE003	required section missing/empty
ISSUE004	REQ ID invalid, duplicate, reused or metadata mismatch
ISSUE005	AC ID invalid, duplicate, reused or metadata mismatch
ISSUE006	MUST REQ uncovered or AC points to missing/retired REQ
ISSUE007	ready contains placeholder, ambiguity or unmet blocker
ISSUE008	blocked lacks target/owner/exit/last check
ISSUE009	HOLD lacks product owner/reason/resume condition
ISSUE010	done lacks prior same-revision PASS ledger, closure or completed state
ISSUE011	semantic change lacks decision/+1, or operational-only event wrongly increments revision
ISSUE012	parent/dependency/supersedes URL invalid or unreadable
ISSUE013	dependency graph self-loop, bidirectional edge or cycle
ISSUE014	one fully qualified REQ has multiple owners
ISSUE015	body status, label and GitHub state/close reason disagree
TRACE001	PR lacks Issue/current revision/REQ/AC trace
TRACE002	diff exceeds declared REQ or violates non-goal
TRACE003	behavior commit lacks required trailers
TRACE004	test cannot map uniquely to AC
TRACE005	evidence type/crosswalk invalid or ledger lacks full SHA/permalink/environment/time/verifier/result
TRACE006	evidence is stale revision, local-only or Draft-only
DOC001	stable docs contain changing status or contradict accepted behavior
SEC001	restricted secret/private/path/email/payload/log data detected
MUT001	mutation differs from approval or concurrent guard

Lint MUST safe-parse YAML with duplicate/unknown-key rejection; compare metadata to REQ/AC headings;
build coverage and DAG graphs; validate the evidence enum and AC crosswalk; distinguish seven-field
semantic diffs from operational events; trace PR/commit/test/ledger; enforce the same-revision
closure order; and scan sensitive content without printing values.

Output schema is requirement-lint-result.v1 with target, revision, result, stable errors/warnings
and checkedAt. Exit codes are exactly 0=PASS, 1=contract violation, 2=target/read failure.
Lint has read-only permissions and MUST NOT auto-edit, comment, label, close or reopen anything.

K. Open-Issue migration

New Issues use this contract after governance delivery. Every existing open Issue receives an
inventory disposition: normalized, next-touch normalization, or approved bot/private-advisory
source, with owner and next gate. Before its next semantic change, transition to ready, new
implementation PR or closure, it is normalized through a separately approved mutation. Closed
history is never bulk rewritten. Repository-specific migration children are downstream of this
parent and are created from the inventory; they do not block this parent being ready.

Requirements

REQ-001 — Stable organization requirement policy

• Statement: The .github default branch MUST contain a stable REQUIREMENTS.md that defines GitHub
  Issues as the requirement source of truth and mirrors the complete canonical executable contract
  in this Issue body; governance and contribution docs MUST link to it without using repository docs
  for changing implementation status.
• User value: A contributor has one durable organization policy for deciding where current
  requirements, historical decisions, and evidence belong.
• Priority: MUST
• Owner: 本 Issue

REQ-002 — Complete Issue record and status contract

• Statement: Organization Issue Forms MUST collect input without inventing REQ/AC authority; at
  triage, a maintainer/product owner MUST normalize the exact body into requirement-record:v1 with
  user problem, product decision, scope/non-goals, stable REQ/AC IDs, dependency DAG, status,
  evidence index, and revision history and MUST pass read-only lint before adding status:ready;
  state definitions MUST distinguish needs-design, ready, blocked, HOLD, and done.
• User value: Contributors can see whether work is a valid problem, executable requirement,
  external blocker, product hold, or accepted delivery without inferring from prose.
• Priority: MUST
• Owner: 本 Issue

REQ-003 — Deterministic read-only lint

• Statement: A deterministic validator MUST check Issue schema/coverage/DAG/revision/state, PR and
  commit trace, AC-linked tests and ledgers, stable-doc boundaries, sensitive information, and
  mutation approval with stable machine codes, JSON output, and exit codes 0=PASS, 1=contract violation, 2=target/read failure; it MUST have no GitHub write permission or auto-fix path.
• User value: Maintainers receive reproducible pass/fail evidence without a bot silently changing
  product requirements.
• Priority: MUST
• Owner: 本 Issue

REQ-004 — End-to-end implementation and closure trace

• Statement: Every behavior-changing PR and commit MUST reference the full owner Issue, current
  Issue revision, and owned REQ/AC IDs; tests MUST map uniquely to AC IDs; only an immutable
  current-revision verification ledger and explicit product closure record MAY satisfy done;
  only user-problem/decision/scope/non-goal/REQ/AC/dependency semantic changes increment revision,
  while status/blocker/evidence/closure events retain it.
• User value: A reviewer can trace delivered behavior to the exact approved requirement and replay
  the evidence used for acceptance.
• Priority: MUST
• Owner: 本 Issue

REQ-005 — Non-destructive open-Issue migration

• Statement: Every open organization Issue MUST receive an inventory disposition of normalized,
  next-touch normalization, or an approved exceptional source such as a bot advisory/private
  advisory, with an owner and next gate; live Issue changes MUST use exact, separately approved
  mutations, while closed history MUST remain unchanged.
• User value: Existing work enters the traceability model without erasing history or allowing an
  unreviewed bulk rewrite.
• Priority: MUST
• Owner: 本 Issue

REQ-006 — Approval and sensitive-information boundary

• Statement: Requirement mutations MUST be guarded by exact repository/Issue/action/body/comment/
  label/state and concurrent-read snapshots plus explicit user approval and post-write readback;
  public artifacts MUST reject secrets, private URLs, host paths, employee email addresses, user
  content, production logs, and other restricted evidence values.
• User value: Governance rollout cannot leak sensitive information or mutate product records beyond
  what the owner reviewed.
• Priority: MUST
• Owner: 本 Issue

依赖 DAG

• Parent: none
• Blocking dependencies: none
• Downstream: none yet; repository-specific migration children are created from the completed
  inventory and then linked with exact URLs, but they are not blocking dependencies of this parent.
• Contract reference: the Canonical executable governance contract in this Issue body; no local
  file or future repository document may replace it as requirement authority.

No product or implementation Issue depends on this record today. This parent owns the shared policy,
template/normalization guide, read-only lint and inventory. Future migration children must each own
one repository, link this parent in both directions, and form an acyclic, downstream-only graph.

Acceptance Criteria

AC-001 — Stable policy publication without normative loss

• Verifies: REQ-001
• Given: the canonical executable contract embedded in this Issue at its current approved revision.
• When: the organization policy PR is independently reviewed and merged.
• Then: REQUIREMENTS.md exists on .github/main and mirrors every normative rule, template,
  status/revision/closure invariant, migration rule, and all 24 stable lint machine codes embedded
  below with zero semantic omissions; GOVERNANCE.md and CONTRIBUTING.md link it; no changing
  implementation status is copied into stable docs; any normative difference first changes this
  Issue through a superseding decision and new semantic revision.
• Evidence required: CI+manual+independent-review

AC-002 — Intake and triage produce a valid current record

• Verifies: REQ-002
• Given: positive fixtures for feature, defect, maintenance, documentation, and cross-repository
  governance work plus fixtures with missing, duplicate, unknown, retired, and placeholder IDs.
• When: each supported Issue Form collects raw input and the maintainer/product-owner triage path
  normalizes that input with the shared template before the requirement linter is exercised.
• Then: forms do not claim to generate authoritative REQ/AC IDs; positive normalized fixtures yield
  exactly one valid requirement-record:v1; invalid fixtures fail with stable codes; no Issue
  containing TBD, template placeholders, an uncovered MUST REQ, an unresolved blocker, or an
  incomplete HOLD contract can receive status:ready.
• Evidence required: test+CI

AC-003 — Read-only validator is deterministic and fail closed

• Verifies: REQ-003, REQ-006
• Given: golden bodies and graph fixtures for every ISSUE*, TRACE*, DOC*, SEC*, and MUT*
  machine code defined by this Issue's canonical executable contract.
• When: validation runs twice offline and once against a read-only GitHub fixture at the same full
  commit SHA.
• Then: byte-equivalent normalized JSON is produced apart from documented checkedAt; exit codes
  are exactly 0/1/2; malformed YAML, stale revisions, DAG cycles, stale evidence, and sensitive
  fixtures fail closed; the workflow token has read-only permissions and no code path invokes a
  GitHub mutation.
• Evidence required: test+CI+security-review

AC-004 — REQ/AC trace reaches explicit closure

• Verifies: REQ-004
• Given: one positive semantic R1 → R2 superseding fixture, one positive
  ready R1 → R1 PASS ledger → closure → done R1 fixture, and negative fixtures for stale revision,
  operational-only revision bump, out-of-scope diff, missing commit trailer, unmapped test, Draft
  PR, local-only SHA, failed ledger, and automatic close keyword.
• When: the PR template, commit parser, test map, ledger parser, and closure gate are validated.
• Then: only the positive current-revision fixture traces every MUST REQ to a merged PR/full SHA and
  every AC to immutable PASS evidence plus explicit product closure; each negative fixture blocks
  done; the positive closure order is same-revision PASS ledger → closure comment → same-revision
  status/label/close mutation → readback; default PR guidance uses Refs and contains no automatic
  close instruction.
• Evidence required: test+CI+manual

AC-005 — Every open Issue has a safe migration disposition

• Verifies: REQ-005
• Given: a read-only, timestamped inventory of every open Issue in each in-scope public repository
  and any private repository visible to the authorized operator.
• When: the migration plan is reviewed repository by repository.
• Then: every row has a full Issue URL (or an approved private opaque reference), current state,
  owner, disposition, next gate, and child migration Issue; no row is silently dropped; no closed
  Issue is edited; each live normalization has a separate exact mutation approval and readback; an
  Issue cannot newly become ready, start a new implementation PR, or close before its required
  next-touch normalization.
• Evidence required: inventory+manual+independent-review

AC-006 — Mutation and visibility boundaries reject unsafe evidence

• Verifies: REQ-006
• Given: fixtures containing a changed concurrent guard, unapproved extra comment, label
  substitution, public-to-private URL leak, credential-shaped value, host path, employee email,
  user payload, production log, and a safe redacted evidence record.
• When: the mutation contract and sensitive-information checks run.
• Then: every unsafe or out-of-approval fixture fails without printing the matched value or calling
  GitHub; only the redacted fixture passes; public records never expose private dependency URLs;
  post-mutation verification requires exact body hash, labels, state, comment count, and URL.
• Evidence required: test+security-review

状态与待决项

• Status: ready
• Reason: normalization-at-triage, parent ownership, scope/non-goals, all six REQ/AC contracts,
  downstream DAG semantics, migration safety and evidence gates are frozen. The technical owner may
  remain unassigned without weakening product readiness. After this Issue is persisted, ready
  authorizes in-scope implementation but does not mark any outcome done or bypass mutation approval.
• Decision owner: @PeterGuy326
• Exit/next review condition: assign an implementation owner and begin the frozen scope under normal
  exact GitHub mutation controls. If user problem, product decision, scope/non-goals, REQ/AC or DAG
  semantics change, append a superseding decision, increment revision, and re-establish ready.
• Last decision: initial-body

证据

• Required evidence: AC-001=CI+manual+independent-review; AC-002=test+CI;
  AC-003=test+CI+security-review; AC-004=test+CI+manual;
  AC-005=inventory+manual+independent-review; AC-006=test+security-review
• Latest verification ledger: none
• Accepted revision: none

Current discovery evidence supports a frozen product requirement: the public .github repository
has organization governance docs, five input-only Issue Forms, a PR template, and a validator, but
none currently enforces the full revisioned REQ/AC trace contract. This is readiness evidence, not
delivery evidence; local drafts and unpushed work do not count as implementation or acceptance.

变更历史

Revision	Effective time	Decision	Superseding comment
R1	2026-08-05T07:52:53Z	Freeze an independent ready governance requirement owner and canonical executable contract using normalization-at-triage; in-scope implementation is product-authorized after persistence	initial-body

[PeterGuy326]

P9 需求治理 — org#8 GitHub Issues as requirements SoT

优先级： P1
状态： ready
产品备注： 本 session 的工作本身就是在践行此 RFC 的原则（issue body = effective requirement, comments = decision history + verification ledger）。

当前执行情况：

• digital-employee 已有 requirement-record.v1 格式 (#42, platform#5)
• 其余 issue 使用 WHY/WHAT/DONE 简化格式
• 暂不强制全部 issue 迁移到 requirement-record.v1，但新建的 P0/P1 issue 建议采用

执行时机： 持续性治理工作，不阻塞 milestone。技术 P9 在每次新建 issue 时遵循即可。