General Proposal · Proposed / Non-Authoritative

Direction Level · Standalone HTML commissioning surface

T104-PH001-AC005-CHECK000 commissioning decision proposal

Detail-depth, Decision-card boundaries, concrete content roles, proposal-file separation, and the post-commissioning task register for general_proposal.

Checkpoint: T104-PH001-AC005-CHECK000
Review cycle: Post-escalation remediation
Version: 0.3.0
Date: 2026-07-12
Status: Draft · pending CHECK000 disposition
Decision owner: HITL (HDO)
Producer: AFK (LLM_Consultant)

Authority boundary. This is the HDO-facing proposal and review surface, not a disposition record. Its recommendation labels, examples, and recording prompts carry no approval or execution authority.

Architectural decisions · AD0 / 4 working selections

Governance decisions · GD0 / 1 working selections

Orientation

What the HDO is being asked to decide

The lanes are independently dispositionable. The AD lane settles proposal-family mechanics. The GD lane settles the execution decomposition and treatment of the already-existing TK001 issue. A governance call does not imply an architectural call, and none of the five Consultant recommendations is pre-approved.

AD lane · four decisions

Internal Detail-depth; technical/architecture card boundary; distinct Detail, Example, and Proposed carry-forward roles; and a conditional one-file/two-file separation rule.

GD lane · one decision

TK001 lineage, the conditional child-task decomposition, issue #326 treatment, declared mint timing, and the already-staged phase-plan registration context.

Architecture lane · AD

Proposal mechanics · four independent pending cards

0 / 4 working selections

AD-1Detail-depth semanticsPending

Should Detail-depth enrich internal Detail content, or activate reserved proposal_level=detail?

Options and tradeoffs

1A · Richer internal Detail content — recommendedKeeps existing general_proposal structure and active proposal altitudes while allowing bounded technical support inside an option.

1B · Activate proposal_level=detailCreates a new authorable proposal altitude, but exceeds this subtype’s authority and requires the reserved-value activation path.

1C · Leave depth ad hocAvoids mechanics work, but leaves authors and reviewers without a reliable depth boundary.

Consultant recommendation

Recommend 1A. Detail-depth is richer internal Detail content under the existing general_proposal structure. proposal_level=detail remains reserved-inactive and is not activated by this proposal.

Rationale and consequence

T104-STD-005-CLAUSE-005 reserves detail; CLAUSE-006 distinguishes the altitude label “Detail Level” from an internal Detail content unit. Selecting 1B stops ordinary carry-forward until the proper PRD/standard authority activates the value.

Illustrative Detail exhibit · bounded internal depth

Illustration only. This shows what an internal Detail block could contain. It is not implementation text and does not activate proposal_level=detail.

Internal Detail

Validation behavior

The author explains the chosen option’s edge conditions, affected fields, and failure behavior here. The block deepens the option; it does not become a separate proposal altitude.

Evidence boundary

The family standard controls reserved altitude vocabulary. Exact subtype mechanics remain a later T104C2 PRD concern if CHECK000 approves this direction.

AD-2Decision-card boundaryPending

What belongs in a general_proposal Decision card when governance or process facts affect the choice?

Options and tradeoffs

2A · Technical/architecture cards; cite process context — recommendedPreserves a sharp decision surface and evidence trail without duplicating plans, gates, issues, or board state.

2B · Mixed technical and process ledgersKeeps all context nearby, but turns proposal cards into competing control records.

2C · Remove process context entirelyKeeps cards narrow, but can hide material constraints and weaken the recommendation’s traceability.

Consultant recommendation

Recommend 2A. Cards carry technical or architecture decisions. Governance/process context may be cited where it changes the tradeoff, but cards are not process ledgers and do not replace the owning plan, issue, checkpoint, gate, or board surface.

Rationale and consequence

This applies the family boundary discipline: cite material owned elsewhere rather than absorbing its authority. The separate GD lane in this package is a bounded HDO decision surface, not a live execution register.

Evidence boundary

T104-STD-005-CLAUSE-003 establishes inter-artifact boundary discipline. Later PRD/guideline wording must turn the approved direction into subtype mechanics.

AD-3Detail, Example, and Proposed carry-forward rolesPending

How should concrete material remain useful to the HDO without being mistaken for approved execution authority?

Options and tradeoffs

3A · Three distinct labeled roles — recommendedMakes explanation, illustration, and candidate downstream text visibly different, at the cost of modest labeling discipline.

3B · Treat all concrete material as DetailSimplifies vocabulary, but examples and candidate specifications can look equally authoritative.

3C · Ban concrete materialEliminates false-authority risk, but makes architecture review abstract and less testable.

Consultant recommendation

Recommend 3A. Detail explains an option; Example illustrates without prescribing; Proposed carry-forward detail presents candidate downstream text that gains authority only after explicit promotion into its owning artifact.

Illustrative exhibit · three content roles

Illustration only. These bounded samples demonstrate labels and authority posture; none is approved implementation material.

Detail

Explains the option

Describe the edge case, design constraint, or consequence that lets the HDO understand the choice.

Illustrative Example

Shows, does not prescribe

detail: { depth: bounded, authority: none }

Proposed carry-forward

Candidate downstream text

“A Detail block SHOULD name the consequence delta.” If accepted, this sentence must be copied or transformed into the authorized PRD/guideline/template before it governs work.

Evidence boundary

Examples may include diagrams, code, fields, enums, paths, or directories. Labeling prevents concrete review aids from masquerading as implementation specifications.

AD-4One-file versus two-file separationPending

When should architecture and governance/process review needs share one proposal file, and when should they split?

Options and tradeoffs

4A · Split only when review needs materially differ — recommendedUses one file when independent lanes and clear boundaries suffice; supports two proposal subjects when owners, authority paths, or timing materially diverge.

4B · Always one fileKeeps a single packet, but process-heavy review can obscure the architecture call.

4C · Always split by categoryMaximizes separation, but creates needless navigation and synchronization for minor context.

Consultant recommendation

Recommend 4A. Separation follows materially different review needs, not category labels alone. Independently dispositionable lanes can coexist in one proposal when they remain bounded; use two files when their owners, authority routes, or review timing require genuinely separate subjects.

Sibling-package evidence, not authority

The accepted P-PH000-AC008-CHECK000 sibling package validated a one-file proposal with two independently dispositioned AD/GD lanes and bounded labeled Detail exhibits. That accepted package is evidence that the one-file branch is workable; it is not a pre-made decision for AC005 and does not settle this pending card.

Illustrative separation test

Illustration only. Apply the test after identifying the actual review contract.

One file

Shared subject

Same HDO review moment; lane independence is explicit; governance context remains bounded.

Two files

Different review contracts

Different owner, authority path, timing, or subject would make one packet misleading.

Never infer

Construction is not approval

A file split or combined lane design does not itself disposition either lane.

Governance lane · GD

Execution register and lineage · one pending card

0 / 1 working selections

GD-1TK001 lineage, issue #326 treatment, and child-task decompositionPending

How should the pre-freeze issue #326 lineage become the first thin execution slice, and when may the selected child-task set mint?

Options and tradeoffs

5A · Amend issue #326 in place under CLAUSE-008D — recommendedKeep issue #326 as the carrier for T104-PH001-AC005-TK001; after conforming approving CHECK000 proof, amend its body in place to the frozen Draft 1 PRD-authority contract with a P-STD-008-CLAUSE-008C/P-STD-008-CLAUSE-008D changelog-comment trail. This avoids carrier churn while preserving the refinement and lineage rationale.

5B · Leave diagnostic TK001 as-isAvoids mutation, but formal execution would repeat duties absorbed into CHECK000. T104-PH001-AC005-TK000 is the retired local precommissioning node, retired pre-freeze on 2026-07-12 alongside T104-PH001-AC005-TK006.

5C · Keep one broad execution taskReduces issue count, but bundles authority, authoring, exemplar, standard, and COMM work beyond a thin tracer-bullet slice.

5D · Retire issue #326 and mint a fresh carrier under CLAUSE-008CAt commissioning, close #326 as retired-unexecuted with a pointer comment, then mint a fresh carrier issue for the same T104-PH001-AC005-TK001 UID carrying the frozen Draft 1 contract. This honestly preserves the re-scoped-continuation reading, at the cost of issue churn; it does not create a new task identity.

5E · Retire TK001 and mint a fresh child task UID under CLAUSE-008CUnder option 5E, issue #326 is closed as retired-unexecuted with a pointer comment, the T104-PH001-AC005-TK001 UID is retired without reuse, and a fresh child task UID (candidate T104-PH001-AC005-TK007) is minted at commissioning carrying Draft 1's contract. 5E conforms to the reading that the commissioned contract is a new deliverable target, under which P-STD-008-CLAUSE-008C requires a new child UID and P-STD-005-CLAUSE-007B forbids reuse of the retired one. Under 5E the register freeze covers TK002–TK005 plus the newly minted UID; under 5A and 5D it covers TK001–TK005.

GAP-003 tension, stated plainly. Issue #326 predates any register freeze. Options 5A and 5D apply the reading that the commissioning package defines a re-scoped continuation of T104-PH001-AC005-TK001; option 5E applies the reading that Draft 1 is a new deliverable target requiring a new child UID. Option 5E was added after adversarial-review Round 1 per HDO authorization. The HDO adjudicates between these readings at CHECK000.

Consultant recommendation

Recommend 5A; preserve 5D and 5E as operable alternatives. After—and only after—a conforming approving CHECK000 record, use the selected carrier route for the frozen Draft 1 contract. Under 5A and 5D, freeze exact UIDs T104-PH001-AC005-TK001 through T104-PH001-AC005-TK005. Under 5E, retire T104-PH001-AC005-TK001 without reuse and freeze T104-PH001-AC005-TK002 through T104-PH001-AC005-TK005 plus the fresh UID minted at commissioning. T104-PH001-AC005-TK000 and T104-PH001-AC005-TK006 were retired pre-freeze on 2026-07-12: TK000’s local precommissioning duties were absorbed into CHECK000, and final-package assembly belongs to GATE001.

Declared task register if commissioned

UID	Owner	Thin target	Mint timing
`T104-PH001-AC005-TK001`	AFK (LLM_Consultant)	Formalize the dispositioned model in the T104C2 PRD authority surface under 5A or 5D; retired without reuse under 5E.	`commissioning`, 5A/5D only
`T104-PH001-AC005-TK007` (candidate)	AFK (LLM_Consultant)	Fresh child UID minted for the same Draft 1 PRD-authority contract if the HDO selects 5E; the final UID is assigned at commissioning.	`commissioning`, 5E only
`T104-PH001-AC005-TK002`	AFK (LLM_Consultant)	Apply the PRD-aligned model to proposal guideline and template authoring surfaces.	`post-selected-Draft-1-carrier`
`T104-PH001-AC005-TK003`	AFK (LLM_Consultant)	Verify exemplar and SP3 dogfooding boundaries.	`post-CHECK001`, evidence-gated
`T104-PH001-AC005-TK004`	AFK (LLM_Consultant)	Classify T104-STD-005 impact.	`post-CHECK001`, evidence-gated
`T104-PH001-AC005-TK005`	HITL (HDO)	Route proven P-STD-005 impact as a COMM-only follow-up; the HDO routing decision sits in its execution path.	`post-CHECK001`, evidence-gated

Phase-plan registration context

The T104-PH001-AC005 activity row and changelog entry are already staged in this commissioning package, per the HDO’s GAP-010 disposition. That ride-along corrects UID registration and does not approve this card, freeze the child register, or authorize issue mutation.

Evidence boundary

The reconciled plan is the task/control contract. Mint timing becomes actionable only after approving CHECK000 proof. No plus-suffixed shorthand is a task identity, and no downstream issue is created, amended, retired, or executed by this HTML.

Governed proof model

Complete CHECK000 record bundle

P-STD-008-CLAUSE-005A requires all four linked legs; no single event substitutes for the bundle.

the merge event as the anchoring auditable platform event;
the commissioning-package PR body carrying the control-node record — scope, the five decision dispositions, evidence links — with the recorded HDO accepting act riding the same PR per P-STD-008-CLAUSE-005I;
the merge-hash-bound ledger comment on parent issue #325;
decision-record linkage — the five CHECK000 decision dispositions as recorded in the PR-body control record and propagated at closeout into the HDO disposition register of the drift-audit analysis (§V.A), with an HDO-authorized SES002 session note strengthening this leg if approved (currently withheld).

The adversarial-review record rides the PR as supporting review evidence, not as the decision record itself.

Carry-forward boundary

What an approving record would—and would not—enable

An approving CHECK000 disposition would freeze the five-card baseline and authorize minting only according to each declared timing. It would not itself amend the T104C2 PRD, proposal guidance, templates, standards, issues, or board state. Those effects require their named downstream tasks, evidence gates, and governed mutations.

Review governance

QA / Iteration and Open Questions registers

QA / Iteration register

Cycle	Date	Surface	Result / treatment
1	June 2026	Markdown baseline	Initial review cycle; bounded direction refined.
2	June 2026	Markdown baseline	Second review cycle; decision boundaries and concrete roles refined.
3	June 2026	Markdown baseline	Third review cycle; precommissioning baseline stabilized, then retired in place as historical predecessor.
WDL reconciliation	2026-07-12	Commissioning package	Plan/register/proof mechanics reconciled to the accepted WDL baseline.
Adversarial Round 0	2026-07-12	CHECK000 HTML and package	RECYCLE; consultant accepted the finding register and routed this Round 1 remediation.
Adversarial-review Round 1	2026-07-12	CHECK000 HTML and package	RECYCLE; fresh gpt-5.6-sol xhigh review reached the two-round merits ceiling and escalated to the HDO.
HDO post-ceiling authorization	2026-07-12	Post-escalation remediation batch	Remediation batch authorized; option 5E added; no further review rounds — consultant verification substitutes.

Open Questions & Emerging Branches register

ID	Question / branch	State	Resolution route
OQ-001	May SES002 be created as a strengthening record?	Open	Authorization withheld pending HDO D-004.
OQ-002	Which Decision 5 carrier route applies?	Open	Pending HDO adjudication at CHECK000: 5A amendment of #326 (recommended), 5D retired-unexecuted closure plus a fresh same-UID carrier, or 5E retirement of TK001 without reuse plus a newly minted child UID.
OQ-003	What is the staged Cloudflare review URL?	Open	Record the staged URL during commissioning-PR assembly.

Traceability strip

External URLs are plain navigation links. Local links resolve from this proposal. None is fetched as a document subresource.

Parent PLAN issue · #325https://github.com/NMAQ1607/prompt/issues/325

Existing TK001 issue · #326https://github.com/NMAQ1607/prompt/issues/326

T104C2 PRD · #98https://github.com/NMAQ1607/prompt/issues/98

Retired Markdown predecessorproposal_T104-PH001-AC005_precommissioning-decision-baseline.md

Reconciled activity plan../plan_T104-PH001-AC005.md

WDL baseline-drift audit../analysis/analysis_T104-PH001-AC005_wdl-baseline-drift-audit.md

Adversarial-review record../analysis/analysis_T104-PH001-AC005-CHECK000_adversarial-review-request.md

Accepted AC008 exemplar · local../../../../../P/workspace/PH000/AC008/proposal/proposal_P-PH000-AC008-CHECK000_workscope-tier-architecture.html

Accepted AC008 exemplar · commit-pinnedCommit 64e6fd19aa4ee14ddb457aaa33b7f824265473bbhttps://github.com/NMAQ1607/prompt/blob/64e6fd19aa4ee14ddb457aaa33b7f824265473bb/artifacts/tasks/P/workspace/PH000/AC008/proposal/proposal_P-PH000-AC008-CHECK000_workscope-tier-architecture.html