Policy: enter ystack roadmap construction mode

[yihanzhu]

Problem

ystack is still being built and is not yet used to run real software development. Applying the future operating human gates to every reversible repository step has turned the agreed roadmap into repeated approval work before there is a product to operate. The team should build the complete roadmap quickly, test continuously, and enable the operating gates before the first real development use.

Outcome

Enter a temporary, ystack-self-only construction mode. The accepted roadmap is the program authorization for building ystack. Roadmap work is delivered as reviewable implementation PRs without separate human gates or repeated child intent, spec, and plan chains.

Construction scope is bound to:

• repository: yihanzhu/ystack;
• starting main: 7a55da73b29c743e588accbcc5e2b0b67060feeb;
• roadmap blob: 43dcaf2e921257f76bf8ecd7543c49745c6e0f39;
• north-star blob: b299f4bc240b02881c5ea2b64d94ed1a8f3a51eb.

Construction flow

• The roadmap and one bounded implementation brief authorize each PR. A unit needs one concern, exact allowed paths, completion evidence, and dependency state; it does not need its own intake, G1, G2, or plan gate.
• Every change still uses a PR. Direct pushes to main, force-pushes, history rewrites, destructive cleanup, and bypassing CI or review remain forbidden.
• Exact required CI and a substantive independent review with no unresolved Important finding are hard machine gates. Tests land with the implementation and run continuously; testing is not deferred until the roadmap is complete.
• After those gates pass on the exact head and base, the construction publisher may merge automatically. merge-ready is only an optional UI projection.
• The manager may invoke the construction publisher only for this repository and only while the committed construction-mode record is active. Author and reviewer roles do not merge.
• A failed, stale, degraded, scope-expanded, ambiguous, exceptional, or review-contested candidate does not merge. It is revised or recorded as blocked by machine evidence; it does not silently widen roadmap authority.
• Roadmap implementation may use ordered units and milestone PRs. It must keep the repository CI-green, restorable, and coherent after every merge.

Inactive boundary

Construction mode does not authorize ystack to operate on a real target, receive production or target credentials, publish releases, install or activate a live profile, change external infrastructure, deploy, or perform irreversible external writes. Code for those capabilities may be built and tested with local fixtures, stubs, sandboxes, and disposable test repositories, but live activation remains off.

The first real use of ystack for development requires an operator-approved operating mode transition. That transition re-enables the accepted human-gate policy before any real target, credential, release, install, profile activation, deployment, or production action. Construction mode cannot activate itself.

Merge controls

The construction transition PR itself must pass exact CI and independent review. The operator has directly authorized this one transition in the active session, including automatic merge after those machine gates. After it merges:

• keep the main-branch pull-request and required-CI rules;
• remove the required approving-review count so a comments-only independent reviewer can satisfy the review evidence without a human click;
• retain deletion and non-fast-forward protection;
• permit only the bounded construction publisher to merge exact reviewed candidates;
• record every merge receipt and resulting main identity.

No change is retroactively accepted. Existing paused work remains preserved until a fresh construction brief explicitly adopts or supersedes it.

Constraints

• This is a temporary bootstrap mode, not the final operating policy.
• It applies only to yihanzhu/ystack; clones and external targets never inherit it.
• CI and independent review remain mandatory. Auto-merge means no human gate, not no quality gate.
• No candidate code, issue text, PR text, comment, or label can authorize tools, credentials, or scope.
• Constitution and workflow changes still require exact machine evidence and must keep the construction-mode boundary intact, but they do not require a human click during construction.
• Keep frozen PR Add the v1 portable core contract validator (inactive) #183 unchanged until a later accepted construction brief records its replacement.
• Keep the existing portable-core parent-plan worktree preserved until construction mode explicitly supersedes or reuses it.
• The construction publisher must fail closed on head, base, CI, review, repository, mode, or scope mismatch.
• Before the first real development use, an operator must merge the operating-mode transition. No agent may waive that activation boundary.

[yihanzhu]

Exact intake draft awaiting current-policy approval

This issue was drafted from the operator request to update human-gate policy before resuming portable-core. Under the policy that is still active today, a user-directed intake needs direct current-session approval of the exact forge title/body digests before G1. This is the final use of that separate chat gate if this policy ships.

• title_sha256: fbf8e0920f1e6870000736088c7f809dd58f086afbd05e9fe55f67fc8d6d7810
• body_sha256: f52352e920fcd4bbb6f813310c0b2bcf024b63827b19cfc44bc296e8a4845bb6
• mode: user-directed
• decision status: awaiting direct operator approval in the active session

No G1 branch, PR, ready state, plan, or implementation is authorized by this comment. After direct approval, the manager will record it immediately and start the normal current-policy artifact chain. Serial implementation units remain a separate follow-up policy concern.

[yihanzhu]

Revised exact intake draft — prior digests are stale

The operator authorized an in-place revision before intake acceptance. The prior title/body digests in comment 5465555792 are stale and unusable. No G1 branch or PR exists.

Current exact forge values:

• title_sha256: 8d4031cdd41cec405d751b6236e1fc8eb6b6531a7c457a6dc836b05a83975382
• body_sha256: 23a6e5395d31e6058d993b8528cc0cf85643ee14b8478754db8a198b480a6e63
• intake_mode: user-directed
• decision status: awaiting direct operator acceptance under the currently active policy

This draft defines eligibility and the serial-unit policy only. It does not enable a publisher, apply the policy retroactively, amend portable-core artifacts, resume its paused plan, create branches or PRs, or authorize implementation.

[yihanzhu]

Direct operator construction-mode authorization

Recorded immediately from the current Codex session on 2026-08-29. The operator explicitly directed: remove all human gates while ystack is being built, auto-merge roadmap work after machine gates, and enable human gates before ystack is used for real development or improvement.

• repository: yihanzhu/ystack
• intake_mode: operator-directed construction transition
• title_sha256: da646efaf3f31e151f7c4a132c652d77e0375f93507f79651d41545473aab8d1
• body_sha256: b444755a8b22675b09b83ab34986e4da89748cffc2c0c75b4d63de7dac378c5b
• roadmap_blob: 43dcaf2e921257f76bf8ecd7543c49745c6e0f39
• north_star_blob: b299f4bc240b02881c5ea2b64d94ed1a8f3a51eb
• decision: PROCEED

This is explicit authorization for one construction-mode transition PR and for machine-gated automatic merge of later roadmap PRs while that committed mode remains active. It does not waive CI, independent review, exact candidate binding, repository scope, inactivity, or the later operator-only operating-mode activation. It does not authorize real targets, credentials, releases, installs, profile activation, deployment, production actions, force-pushes, or direct main pushes.