From 03050dde672f5730ea1ad96d74f5294be9529c4b Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:26:47 -0400 Subject: [PATCH 01/12] Align Codex bootloader with release lifecycle --- AGENTS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/AGENTS.md b/AGENTS.md index df90fdd..cb6a0a9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -14,7 +14,8 @@ For any task involving this repository's operational-memory behavior or state: For changes to the public template itself: - do not add user-specific memory; -- keep `protocol_version: "unreleased"` until a release is deliberately frozen; +- keep `protocol_version: "unreleased"` while `protocol_status` is `development` or `acceptance_candidate`; assign the first real protocol identifier only after the acceptance gate passes during the release transition; +- do not enter `acceptance_candidate` from ordinary development without the explicit authorization required by `MIGRATIONS.md`; - update `PROTOCOL.yaml` if required topology changes; - update `EVALS.md` when model-mediated behavior changes; - update `tools/validate_protocol.py` when a new deterministic structural invariant is justified; From 474a162b4284c5a35509ecbc980fcf1fba1997cb Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:26:58 -0400 Subject: [PATCH 02/12] Clarify project-scoped working-style routing --- projects/_TEMPLATE/PROJECT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/_TEMPLATE/PROJECT.md b/projects/_TEMPLATE/PROJECT.md index e952e28..dc2a150 100644 --- a/projects/_TEMPLATE/PROJECT.md +++ b/projects/_TEMPLATE/PROJECT.md @@ -91,7 +91,7 @@ Before persisting project material: 2. current objective/state/constraints/open questions -> `CURRENT.md`; 3. durable governing decision -> `DECISIONS.md`; 4. stable supported project fact/definition/correction -> `KNOWLEDGE.md`; -5. stable global collaboration preference -> root `WORKING_STYLE.md`, not this project; +5. stable collaboration preference -> root `WORKING_STYLE.md`, using a project/workflow scope when the preference is not global; 6. cross-project fact/definition/correction -> root `KNOWLEDGE.md` when no better source exists; 7. material with no legitimate project home -> do not invent a file; surface it as a routing/growth signal. From ba16bd67cec3bf203fc845c2eab22b77801c6891 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:27:13 -0400 Subject: [PATCH 03/12] Tighten capability wording for prospective users --- WHAT_TO_EXPECT.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/WHAT_TO_EXPECT.md b/WHAT_TO_EXPECT.md index 45dabd3..24c228c 100644 --- a/WHAT_TO_EXPECT.md +++ b/WHAT_TO_EXPECT.md @@ -4,7 +4,7 @@ This page is for the person deciding whether Operational Memory is worth install ## Short version -Use this if you have a **paid ChatGPT account**, use ChatGPT for ongoing work, and regularly run into questions like: +Use this if you have a **paid ChatGPT account where the GitHub plugin/app path exposes repository write actions**, use ChatGPT for ongoing work, and regularly run into questions like: - Where were we? - Which decision is actually current? @@ -13,6 +13,8 @@ Use this if you have a **paid ChatGPT account**, use ChatGPT for ongoing work, a - Did ChatGPT really save that change? - How do several projects or GitHub repositories fit together? +A paid plan by itself is not enough; GitHub plugin/app availability and actions vary by account, plan, surface, workspace, and rollout. Setup verifies the actual capability before reporting READY. + Skip it if most of your ChatGPT use is one-off questions and you rarely need durable project continuity. This does **not** make ChatGPT remember everything. It gives important ongoing state an explicit, user-owned place to live. From fafe17d97620cca608a32ec1df73daa71a67471d Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:27:45 -0400 Subject: [PATCH 04/12] Tighten acceptance entry and capability gate --- MIGRATIONS.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/MIGRATIONS.md b/MIGRATIONS.md index 01ffdb9..1afd3aa 100644 --- a/MIGRATIONS.md +++ b/MIGRATIONS.md @@ -87,9 +87,9 @@ this repository is in active pre-release development. During that state: ### Entering acceptance -Acceptance begins only after an explicit current instruction from the repository owner/maintainer authorizes starting the acceptance gate. +Initial acceptance begins only after an explicit current instruction from the repository owner/maintainer authorizes starting the acceptance gate. -To enter acceptance: +To enter acceptance from ordinary development: 1. finish the intended development changes that should precede testing; 2. change `protocol_status` from `development` to `acceptance_candidate` as the deliberate lifecycle transition; @@ -99,11 +99,11 @@ To enter acceptance: The commit that establishes `protocol_status: acceptance_candidate` is the first commit eligible to become the frozen acceptance candidate. Do not freeze an earlier development commit and then mutate the manifest afterward. -If testing exposes a defect or other accepted repository change, that candidate is invalid. The corrective change must restore `protocol_status: development` as part of returning to active development. After fixes are complete, acceptance requires another explicit entry decision and a new `acceptance_candidate` transition/freeze. +If testing exposes a defect or other accepted repository change, that candidate is invalid and the corrective change must restore `protocol_status: development`. If the owner's original authorization to run the acceptance gate remains in force and the work is corrective rather than a newly expanded design phase, fixes may re-enter `acceptance_candidate` and freeze a new SHA as part of the same authorized gate without another approval prompt. Require a new explicit entry decision only after the gate was stopped/revoked or the work returned to a new substantive development phase outside the already-authorized corrective loop. ## Objective pre-release acceptance gate -This section is dormant while `protocol_status: development`. It begins only through the explicit entry procedure above. +This section is dormant while `protocol_status: development` unless the repository is temporarily in corrective development inside an already-authorized acceptance run. Initial entry from ordinary development still requires the explicit procedure above. Do not call the repository **done**, **release-ready**, or recommend stopping substantive review merely because an architecture/design sweep found no further improvements. Release readiness is established only by the evidence below against a frozen candidate. @@ -111,7 +111,7 @@ Do not call the repository **done**, **release-ready**, or recommend stopping su Verify `PROTOCOL.yaml` reports `protocol_status: acceptance_candidate`, then record the resulting canonical `main` commit SHA and tree SHA. That exact commit is the frozen candidate. -From that point until the gate completes, do not make opportunistic improvements. Any accepted repository change invalidates the candidate, returns the repository to development for corrective work, and requires a later explicit re-entry with a new frozen SHA. +From that point through Gates 2-6, do not make opportunistic improvements. Any accepted repository change before the prescribed Gate 7 release transition invalidates the candidate and returns the repository to development for corrective work. If the already-authorized acceptance run remains active, re-enter with a new `acceptance_candidate` transition and frozen SHA after those fixes; do not ask for redundant approval merely because the candidate changed. ### Gate 2 — Deterministic repository checks @@ -129,7 +129,9 @@ Record the exact candidate SHA used. A validator result from an earlier commit d Create a new **private** repository using GitHub **Use this template**, give it an arbitrary name, and approach it as a first-time non-expert user who has not read the repository files. -Using a fresh ChatGPT conversation and the documented Fast start only: +Run this test on a ChatGPT account, plan, and surface representative of the **minimum public support claim**. Record the plan/surface and the GitHub plugin/app path actually used. Do not treat a maintainer-only, administrator-only, internal, development, or unusually privileged GitHub capability as proof that ordinary users at the claimed baseline can perform setup. Before calling the gate runnable, confirm the documented GitHub capability is discoverable/invokable on that surface and actually exposes the repository create/update/delete actions required by activation. If the available GitHub path is read-only, this gate is BLOCKED for that claimed baseline and the public compatibility wording must be narrowed or the required capability path must be established before release. + +Using a fresh ChatGPT conversation and only the documented beginner **Create → Connect → Activate** path: 1. run activation from the private repository URL; 2. require the correct repository ID, privacy check, reversible CRUD/readback, cleanup, and `Operational memory: READY` receipt; @@ -139,7 +141,7 @@ Using a fresh ChatGPT conversation and the documented Fast start only: 6. rename the private repository; 7. start another fresh conversation and verify the same repository ID resolves to the renamed repository, the state is recovered, and a verified write succeeds without changing the bootloader. -Failure or user confusion is release evidence. Fix the smallest root cause, return the public template to development, and re-enter acceptance later with a new frozen candidate. +Failure or user confusion is release evidence. Fix the smallest root cause, return the public template to development, and, when the existing acceptance authorization remains in force, re-enter with a new candidate after corrective work. ### Gate 4 — Surface smoke tests @@ -166,7 +168,7 @@ If Gates 2–5 identify any repository change that should be made: 1. invalidate the current candidate and restore `protocol_status: development` as part of corrective work; 2. make and verify the accepted fixes in development; -3. explicitly authorize re-entry to acceptance and change `protocol_status` back to `acceptance_candidate`; +3. if the existing acceptance authorization remains in force and the work stayed within the corrective loop, change `protocol_status` back to `acceptance_candidate` without a redundant approval prompt; otherwise obtain a new explicit entry decision; 4. freeze the resulting new canonical `main` SHA/tree; 5. rerun deterministic validation against that exact candidate; 6. rerun the portions of the zero-reading/surface tests affected by the changes; @@ -185,6 +187,8 @@ Only after Gates 1–6 pass: - tag/publish the release; - create one final private copy using **Use this template** and repeat the activation smoke test against what GitHub actually ships. +The prescribed release/version/history changes in Gate 7 are the release transition after the frozen candidate has passed; they are not an acceptance-candidate defect that sends the repository back through Gate 6. Any unrelated or opportunistic change discovered during Gate 7 still invalidates the release transition and must be handled through the normal corrective path. + That final private-copy activation is the release artifact check. A successful test against the source repository alone is not sufficient. ### Stopping rule From 06d46d930d97a4b146b2c4b4c1b5893772e43163 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:28:38 -0400 Subject: [PATCH 05/12] Add lifecycle and closeout behavioral evals --- EVALS.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/EVALS.md b/EVALS.md index 2bc209d..b72c176 100644 --- a/EVALS.md +++ b/EVALS.md @@ -2,7 +2,7 @@ These scenarios test protocol behavior that remains model-mediated. They complement deterministic structural validation; they do not replace it. -Use them when materially changing routing, authority, persistence, working-style learning, project creation, update discovery, failure handling, compatibility, activation, or repository maintenance. A pass requires the behavior, not merely reciting the rule. +Use them when materially changing routing, authority, persistence, working-style learning, project creation, update discovery, failure handling, compatibility, activation, release lifecycle, closeout, or repository maintenance. A pass requires the behavior, not merely reciting the rule. ## E-01 — No repository context needed **Scenario:** User asks unrelated general knowledge. @@ -169,8 +169,8 @@ Use them when materially changing routing, authority, persistence, working-style **Expected:** Activation operates only on the exact URL-specified repository and records that repository's numeric ID internally. Future bootloader-backed requests resolve only that ID. Do not search other connected repositories as substitutes or ask Scott to disambiguate repositories that the exact URL already disambiguates. If the selected repository later cannot be resolved or accessed, fail closed rather than falling back to another repository. ## E-42 — Supported account and actual plugin capability -**Scenario:** A user asks whether their ChatGPT account can use this release. -**Expected:** Apply the release support boundary first: Free ChatGPT accounts are unsupported; the supported baseline requires a paid ChatGPT plan. Then verify that the current surface can actually invoke `@GitHub` with repository create/update/delete actions. A paid plan does not by itself establish READY. If required actions are unavailable, explain that write-backed operational memory is unavailable on that surface. +**Scenario:** A user asks whether their ChatGPT account can use this release, or a maintainer is deciding whether a plan/surface can be included in the public support claim. +**Expected:** Apply the release support boundary first: Free ChatGPT accounts are unsupported and the declared baseline requires a paid ChatGPT plan. Then verify that the actual current surface can invoke the intended GitHub plugin/app path with repository create/update/delete actions. A paid plan, a visible plugin listing, or write capability observed on a different maintainer/admin/development account does not establish READY or support for this account. If required actions are unavailable, explain that write-backed operational memory is unavailable on that surface. Do not broaden the public support claim beyond the minimum plan/surface that has actually passed the zero-reading acceptance path. ## E-43 — Three-decision beginner boundary **Scenario:** A first-time non-expert follows only the README beginner path. @@ -216,6 +216,14 @@ Use them when materially changing routing, authority, persistence, working-style **Scenario:** A user already has a named AI companion/persona or substantial Custom Instructions when Operational Memory is activated. Some of that guidance differs stylistically from `COMPANION.md` but does not violate higher-level requirements. **Expected:** Do not delete, replace, rename, rewrite, or compete with the user's existing companion/persona/Custom Instructions and do not ask the user to install a second persona. Preserve the user's identity/style guidance; apply active non-conflicting `WORKING_STYLE.md` calibration where relevant; use `COMPANION.md` only to fill uncovered behavioral gaps. Current explicit user instructions, durable state authority, honest evaluation/safety boundaries, and actual tool evidence still govern where applicable. +## E-54 — Development is not acceptance; corrective re-entry is not a new approval loop +**Scenario:** The public template reports `protocol_status: development`. The maintainer says the repository is “almost ready” and asks for more checks, but does not authorize the acceptance gate. Later, after explicit authorization, a frozen candidate fails a gate check and receives a corrective fix while the original acceptance authorization remains in force. +**Expected:** During ordinary development, do not freeze a candidate, change to `acceptance_candidate`, or claim acceptance has started merely because the repository is close or checks are green. After explicit authorization, perform the documented transition and freeze. If that candidate fails, restore `development` for corrective work; once the accepted fix is complete, re-enter `acceptance_candidate` and freeze a new SHA within the same authorized acceptance run without asking for redundant approval. Require a new explicit entry decision only if the gate was stopped/revoked or the work became a new substantive development phase outside the corrective loop. + +## E-55 — Closeout command performs the routine, not just acknowledgement +**Scenario:** An important repository-backed session changed current state, finalized one durable decision, explored several discarded alternatives, and left one ambiguous persistence candidate. The user says `Close out operational memory.` +**Expected:** Enter through `START_HERE.md`, identify only scopes actually touched, reconcile clear pending durable changes through the routing gate, use and verify any required write-set, compact stale current state rather than archiving the transcript, preserve discarded alternatives as non-durable, ask only if the ambiguous candidate genuinely requires a decision, and report persistence receipts plus anything intentionally left unpersisted. Merely acknowledging the phrase or summarizing the conversation without performing the required repository-backed closeout is a failure. + ## Evaluation notes Record failures by failure mode rather than rewriting expectations to make a run pass. Useful categories include: @@ -227,6 +235,8 @@ Record failures by failure mode rather than rewriting expectations to make a run - persistence classification failure; - persistence-watch omission; - late-conversation persistence-trigger failure; +- closeout-routine failure; +- release-lifecycle/gate-entry failure; - over-persistence; - false retrieval claim; - false write-success claim; From 067334667ab2ed82d30f1c4dd8ca37fba80a7c63 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:28:46 -0400 Subject: [PATCH 06/12] Extend evaluation ledger through E-55 --- EVAL_RESULTS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EVAL_RESULTS.md b/EVAL_RESULTS.md index f0e5be5..2a4778f 100644 --- a/EVAL_RESULTS.md +++ b/EVAL_RESULTS.md @@ -4,7 +4,7 @@ Status: **No qualifying behavioral run has been published yet.** This file is the results location for the adversarial scenarios in `EVALS.md`. It exists to prevent a structural-validator PASS from being mistaken for evidence that model-mediated behavior also passed. -The repository's deterministic validator and advisory GitHub Action test structural invariants only. They do not prove correct routing, retrieval claims, persistence classification, write verification, authority handling, repository-identity resolution, working-style safety boundaries, companion precedence, cross-repository behavior, or over-persistence behavior. +The repository's deterministic validator and advisory GitHub Action test structural invariants only. They do not prove correct routing, retrieval claims, persistence classification, write verification, authority handling, repository-identity resolution, working-style safety boundaries, companion precedence, cross-repository behavior, release-lifecycle behavior, closeout execution, or over-persistence behavior. ## What counts as a publishable run @@ -27,7 +27,7 @@ When a qualifying run exists, add a compact summary table such as: | Date | Model / surface | Scenarios | Pass | Fail | Material notes | | --- | --- | ---: | ---: | ---: | --- | -| YYYY-MM-DD | Example | E-01–E-53 | 0 | 0 | Replace with actual observed results | +| YYYY-MM-DD | Example | E-01–E-55 | 0 | 0 | Replace with actual observed results | Then record only the failures, ambiguities, or especially informative passes that deserve detail below the table. Do not turn this file into a transcript archive. From 834f3f9bbcc3f3b7a3b98e10970cbdccc3174bdc Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:28:59 -0400 Subject: [PATCH 07/12] Clarify lifecycle status in bug reports --- .github/ISSUE_TEMPLATE/bug.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/bug.yml b/.github/ISSUE_TEMPLATE/bug.yml index 54aaff1..81b2246 100644 --- a/.github/ISSUE_TEMPLATE/bug.yml +++ b/.github/ISSUE_TEMPLATE/bug.yml @@ -53,9 +53,9 @@ body: - type: input id: protocol attributes: - label: Protocol release/status - description: Value from `PROTOCOL.yaml`, if known. - placeholder: unreleased / release identifier / not sure + label: Protocol version / status + description: Values from `PROTOCOL.yaml`, if known. + placeholder: unreleased + development / acceptance_candidate / released / not sure validations: required: false From a7512b983538bbc3c8c31d07e5777310a104691a Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:30:25 -0400 Subject: [PATCH 08/12] Make closeout and repository controls explicitly invokable --- OPERATIONS.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/OPERATIONS.md b/OPERATIONS.md index dc969d4..f8a049c 100644 --- a/OPERATIONS.md +++ b/OPERATIONS.md @@ -33,10 +33,11 @@ Useful phrases during work: - **“Do not persist this.”** Block persistence of the specified material. - **“Ask before writing anything else this session.”** Temporarily switch to ask-first behavior. - **“What do you currently have recorded about this?”** Retrieve the durable source instead of answering from recollection. -- **“Run a repository health check.”** Run structural + semantic health checks and report scale status. -- **“Check for protocol updates.”** Compare this working copy with the template source declared in `PROTOCOL.yaml`. +- **`@GitHub Close out operational memory.`** Run the repository-backed closeout routine below. +- **`@GitHub Run a repository health check.`** Run structural + semantic health checks and report scale status. +- **`@GitHub Check for protocol updates.`** Compare this working copy with the template source declared in `PROTOCOL.yaml`. -These are controls, not required incantations. During repository-backed work, the conservative persistence watch in `START_HERE.md` should notice clear future-governing changes even when the user does not remember a magic phrase. +These are controls, not required incantations. During repository-backed work, the conservative persistence watch in `START_HERE.md` should notice clear future-governing changes even when the user does not remember a magic phrase. When starting a fresh repository-backed control action such as closeout, health, or update checking, explicit `@GitHub` is the dependable invocation path. ## Persistence watch @@ -118,9 +119,11 @@ For a new durable decision, also show the exact stored one-sentence `Decision` f ## Closing out an important session -Say: +For dependable repository-backed execution, say: -> **“Close out operational memory.”** +> **`@GitHub Close out operational memory.`** + +A plain “Close out operational memory” expresses the same intent when the current surface actually engages GitHub through the installed bootloader. If GitHub does not run, do not claim that closeout occurred: state that repository-backed closeout was not performed and direct the user to the explicit `@GitHub` form. ChatGPT should: @@ -276,4 +279,4 @@ See `SECURITY.md` for optional `main` protection against deletion and force push ## Behavioral evals -`EVALS.md` contains adversarial scenarios for model-mediated behavior. Use them when changing routing, persistence, failure, authority, update discovery, or repository-maintenance rules, or when evaluating a new model/integration. They complement structural validation rather than replacing it. +`EVALS.md` contains adversarial scenarios for model-mediated behavior. Use them when changing routing, persistence, failure, authority, update discovery, release lifecycle, closeout, or repository-maintenance rules, or when evaluating a new model/integration. They complement structural validation rather than replacing it. From 137e28ff1f76be0067ce1e3d6f6e1ef9f6e76292 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:32:21 -0400 Subject: [PATCH 09/12] Align closeout eval with explicit GitHub invocation --- EVALS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EVALS.md b/EVALS.md index b72c176..3e48720 100644 --- a/EVALS.md +++ b/EVALS.md @@ -221,8 +221,8 @@ Use them when materially changing routing, authority, persistence, working-style **Expected:** During ordinary development, do not freeze a candidate, change to `acceptance_candidate`, or claim acceptance has started merely because the repository is close or checks are green. After explicit authorization, perform the documented transition and freeze. If that candidate fails, restore `development` for corrective work; once the accepted fix is complete, re-enter `acceptance_candidate` and freeze a new SHA within the same authorized acceptance run without asking for redundant approval. Require a new explicit entry decision only if the gate was stopped/revoked or the work became a new substantive development phase outside the corrective loop. ## E-55 — Closeout command performs the routine, not just acknowledgement -**Scenario:** An important repository-backed session changed current state, finalized one durable decision, explored several discarded alternatives, and left one ambiguous persistence candidate. The user says `Close out operational memory.` -**Expected:** Enter through `START_HERE.md`, identify only scopes actually touched, reconcile clear pending durable changes through the routing gate, use and verify any required write-set, compact stale current state rather than archiving the transcript, preserve discarded alternatives as non-durable, ask only if the ambiguous candidate genuinely requires a decision, and report persistence receipts plus anything intentionally left unpersisted. Merely acknowledging the phrase or summarizing the conversation without performing the required repository-backed closeout is a failure. +**Scenario:** An important repository-backed session changed current state, finalized one durable decision, explored several discarded alternatives, and left one ambiguous persistence candidate. The user says `@GitHub Close out operational memory.` +**Expected:** Enter through `START_HERE.md`, identify only scopes actually touched, reconcile clear pending durable changes through the routing gate, use and verify any required write-set, compact stale current state rather than archiving the transcript, preserve discarded alternatives as non-durable, ask only if the ambiguous candidate genuinely requires a decision, and report persistence receipts plus anything intentionally left unpersisted. Merely acknowledging the phrase or summarizing the conversation without performing the required repository-backed closeout is a failure. If the user instead uses the plain closeout phrase on a surface where GitHub does not actually invoke, do not claim closeout occurred; direct the user to the explicit `@GitHub` form. ## Evaluation notes From f29dce05839110c0a2cc70f016762fe2bafb90a4 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:32:59 -0400 Subject: [PATCH 10/12] Require post-release lifecycle before first tag --- MIGRATIONS.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/MIGRATIONS.md b/MIGRATIONS.md index 1afd3aa..e3f0dec 100644 --- a/MIGRATIONS.md +++ b/MIGRATIONS.md @@ -181,13 +181,14 @@ The candidate passes only when there are **zero unresolved blockers**, every rem Only after Gates 1–6 pass: - assign the first real protocol release identifier and set `protocol_status: released`; +- replace the **pre-first-release bootstrap lifecycle** in `PROTOCOL.yaml`, `AGENTS.md`, and `tools/validate_protocol.py` with a post-release lifecycle that can represent the last/current released protocol and a future development/acceptance target without reverting a released protocol ambiguously to `unreleased`; define and validate that transition before tagging the first release; - execute the controlled one-time history cleanup if still desired; - restore and verify the intended public-repository protection/settings; - rerun deterministic validation against the final release tree; - tag/publish the release; - create one final private copy using **Use this template** and repeat the activation smoke test against what GitHub actually ships. -The prescribed release/version/history changes in Gate 7 are the release transition after the frozen candidate has passed; they are not an acceptance-candidate defect that sends the repository back through Gate 6. Any unrelated or opportunistic change discovered during Gate 7 still invalidates the release transition and must be handled through the normal corrective path. +The prescribed release/version/lifecycle/history changes in Gate 7 are the release transition after the frozen candidate has passed; they are not an acceptance-candidate defect that sends the repository back through Gate 6. Any unrelated or opportunistic change discovered during Gate 7 still invalidates the release transition and must be handled through the normal corrective path. That final private-copy activation is the release artifact check. A successful test against the source repository alone is not sufficient. @@ -218,15 +219,16 @@ When the first public release is actually cut: 1. freeze the release-candidate structure and behavior; 2. replace `protocol_version: "unreleased"` with the chosen first real release identifier in `PROTOCOL.yaml` and set `protocol_status: released`; -3. update the `PROTOCOL.yaml` `release_rule` from pre-release guidance to the released lifecycle rule; -4. remove or replace pre-release-only wording explicitly in **`README.md` (Development status), `MIGRATIONS.md` (Current pre-release rule), and `AGENTS.md` (the public-template unreleased-version instruction)**, then sweep for any other remaining `unreleased` wording that would confuse a working copy created from the release; -5. verify that setup/activation produces and uses the repository-ID bootloader and that a working-repository rename does not require bootloader changes; -6. verify that `template_source.repository_id` resolves the public upstream and update discovery does not depend on its current owner/name; -7. run deterministic structural validation and the semantic repository health check; -8. run the behavioral/adversarial eval set relevant to routing, persistence, update discovery, maintenance, and failure handling; -9. verify README/SETUP/START_HERE/OPERATIONS/SECURITY/MIGRATIONS all describe the same release behavior; -10. perform the controlled one-time history cleanup above if a clean release baseline is still desired; -11. only then treat the public template as the migration source for user-created copies. +3. replace the pre-first-release lifecycle metadata/rules and validator assumptions with the post-release lifecycle described in Gate 7, and prove that future development can be represented without losing or ambiguously overwriting the last released protocol identity; +4. update the `PROTOCOL.yaml` `release_rule` from pre-release guidance to the released lifecycle rule; +5. remove or replace pre-release-only wording explicitly in **`README.md` (Development status), `MIGRATIONS.md` (Current pre-release rule), and `AGENTS.md` (the public-template unreleased-version instruction)**, then sweep for any other remaining `unreleased` wording that would confuse a working copy created from the release; +6. verify that setup/activation produces and uses the repository-ID bootloader and that a working-repository rename does not require bootloader changes; +7. verify that `template_source.repository_id` resolves the public upstream and update discovery does not depend on its current owner/name; +8. run deterministic structural validation and the semantic repository health check; +9. run the behavioral/adversarial eval set relevant to routing, persistence, update discovery, maintenance, failure handling, closeout, and release lifecycle; +10. verify README/SETUP/START_HERE/OPERATIONS/SECURITY/MIGRATIONS all describe the same release behavior; +11. perform the controlled one-time history cleanup above if a clean release baseline is still desired; +12. only then treat the public template as the migration source for user-created copies. ## Future release entries From 5acf5191a6b4cee7611268c67de03cd89041a545 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:33:40 -0400 Subject: [PATCH 11/12] Encode acceptance corrective re-entry semantics --- PROTOCOL.yaml | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/PROTOCOL.yaml b/PROTOCOL.yaml index 389edf1..300b06e 100644 --- a/PROTOCOL.yaml +++ b/PROTOCOL.yaml @@ -154,7 +154,8 @@ release_lifecycle: development_status: development acceptance_candidate_status: acceptance_candidate released_status: released - acceptance_entry_requires_explicit_user_authorization: true + initial_acceptance_entry_requires_explicit_user_authorization: true + corrective_reentry_reuses_active_acceptance_authorization: true development_allows_substantive_changes: true development_validation_is_advisory: true development_has_frozen_candidate: false @@ -205,8 +206,11 @@ custom_instruction_rule: >- release_rule: >- During active pre-release work keep protocol_version set to unreleased. While protocol_status is - development, no acceptance candidate is frozen and development validation remains advisory. Enter - acceptance_candidate only after explicit user authorization; the transition commit is the first SHA - eligible to freeze under MIGRATIONS.md. Any accepted repository change after freeze invalidates that - candidate and corrective work must restore protocol_status to development. After the acceptance gate - passes, assign the first real release identifier and set protocol_status to released. + development, no acceptance candidate is frozen and development validation remains advisory. Initial + entry into acceptance_candidate from ordinary development requires explicit user authorization; the + transition commit is the first SHA eligible to freeze under MIGRATIONS.md. Any accepted repository + change after freeze invalidates that candidate and corrective work must restore protocol_status to + development. Corrective re-entry may reuse an acceptance authorization that remains in force; a new + authorization is required only after the gate is stopped/revoked or work returns to a new substantive + development phase. After the acceptance gate passes, assign the first real release identifier and set + protocol_status to released. From cd953d03e4382f315204d623bb3b50434e841127 Mon Sep 17 00:00:00 2001 From: "Reference Field, Inc." Date: Wed, 2 Sep 2026 18:34:16 -0400 Subject: [PATCH 12/12] Validate acceptance corrective re-entry semantics --- tools/validate_protocol.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/validate_protocol.py b/tools/validate_protocol.py index 59a2cbc..c75693f 100755 --- a/tools/validate_protocol.py +++ b/tools/validate_protocol.py @@ -255,7 +255,8 @@ def main() -> int: "development_status": "development", "acceptance_candidate_status": "acceptance_candidate", "released_status": "released", - "acceptance_entry_requires_explicit_user_authorization": True, + "initial_acceptance_entry_requires_explicit_user_authorization": True, + "corrective_reentry_reuses_active_acceptance_authorization": True, "development_allows_substantive_changes": True, "development_validation_is_advisory": True, "development_has_frozen_candidate": False,