Fix usage waste, silent psychology drift, and lost-work checkpoints

adapters/chatgpt/metadata/chatgpt-adapter.json

@@ -7,7 +7,7 @@
   "adapter_path": "adapters/chatgpt/selective-intelligence",
   "transformation": "runtime_only_with_nested_role_entrypoints_as_role_references",
   "single_skill_entrypoint": "SKILL.md",
-  "runtime_file_count": 47,
+  "runtime_file_count": 50,
   "role_path_map": {
     "subskills/si-aligner/SKILL.md": "subskills/si-aligner/ROLE.md",
     "subskills/si-intake/SKILL.md": "subskills/si-intake/ROLE.md",

adapters/chatgpt/selective-intelligence/references/durable-progress-and-recovery.md

@@ -0,0 +1,116 @@
+# Durable progress and recovery
+
+Use this whenever work can outlive one response, tool run, context window, worker, or workspace. Completed work must become recoverable before the next risky step begins.
+
+## Anti-loss invariant
+
+Never hold more than one coherent completed slice or five materially changed files without a durable checkpoint.
+
+A coherent slice is a bounded outcome that can be explained, inspected, and resumed independently, such as a repaired route, completed component state, migration draft, research decision, document section, or verified artifact.
+
+## Checkpoint order
+
+For authorized repository work:
+
+1. Inspect the current branch, revision, dirty changes, and unrelated work.
+2. Select only files owned by the current slice.
+3. Run the fastest relevant validation that can catch a destructive save.
+4. Write the progress record.
+5. Commit the selected files and record on the existing task branch.
+6. Push when remote writing is available and local-only work was not required.
+7. Verify the remote branch contains the checkpoint revision.
+8. Record proof and the next safe action.
+9. Only then begin a long command, new slice, handoff, or context change.
+
+Never stage all changes blindly. Never discard or rewrite unrelated work to create a clean checkpoint.
+
+## Bundled work guard
+
+Use `scripts/progress_checkpoint.py` when it can run.
+
+Its progress commands create a bounded recovery record, selectively commit task-owned files, push the existing task branch, verify the remote revision, preserve unrelated changes, and reject routine checkpoint commits to protected branches.
+
+Its usage commands open a private evidence ledger before a second persistent repository batch. They reject more than 12 files or 64 KB in one batch, overlapping ownership of the same question, and a fourth search or inspection batch without an `act`, `narrow`, `checkpoint`, or `stop` decision.
+
+When the helper cannot run, reproduce the same behavior with available repository tools. Do not continue after a checkpoint or usage-stop trigger until the required state is observed.
+
+The helper keeps one tracked `latest.json` recovery record. Git history provides the checkpoint timeline, preventing one new tracked file per save. Local operation and usage receipts remain in the repository-private Git area and do not dirty the working tree.
+
+## Safe branch policy
+
+Routine preservation belongs on an existing non-protected task branch. It does not belong directly on `main`, `master`, `trunk`, `production`, `prod`, or release branches without exact authorization.
+
+A progress push is preservation, not publication. It does not authorize:
+
+- opening or merging a pull request;
+- changing the default branch;
+- releasing a package;
+- deploying;
+- running a production migration;
+- changing credentials, access, billing, DNS, or provider settings.
+
+## Minimum progress record
+
+Store a concise, privacy-safe record containing:
+
+- checkpoint identifier and time;
+- outcome, active correction, scope, and prohibitions;
+- completed and verified work;
+- changed but unverified work;
+- repository-relative location, branch, base revision, and containing commit;
+- task-owned files included;
+- tests, rendered proof, and known failures;
+- external effects with receipts;
+- actions not to repeat;
+- current blockers;
+- next safe action;
+- exact remaining authority step.
+
+Do not store secrets, absolute local paths, unrelated file names, raw private prompts, hidden reasoning, or unnecessary customer data.
+
+## Before long operations
+
+Checkpoint before:
+
+- dependency installation or a large build;
+- broad test suites;
+- migration generation or rehearsal;
+- image processing, crawling, or bulk import;
+- deployment preparation;
+- cross-repository integration;
+- changing models, workers, contexts, branches, or worktrees;
+- any operation whose failure could erase the ability to explain or recover current work.
+
+A successful command does not preserve earlier uncommitted work. Save first.
+
+## External effects
+
+After sending, publishing, purchasing, deploying, migrating, changing access, or triggering another provider, record the exact target, action, observed result, receipt or revision, retry safety, and rollback path.
+
+An unknown result is neither failure nor success. Inspect actual state before retrying.
+
+## Resume protocol
+
+1. Load the latest durable checkpoint.
+2. Inspect actual repository and external state.
+3. Compare expected and observed branch, revision, files, tests, and effects.
+4. Classify the checkpoint as current, interrupted, superseded, conflicting, or reconciled.
+5. Resume from the first unproved state transition.
+6. Revalidate proof invalidated by shared changes.
+7. Save a new checkpoint after the recovered slice.
+
+Do not restart the original plan from step one. Do not repeat external actions because a new worker cannot see their result.
+
+## Fallback without Git
+
+Write the record and completed artifact to a durable project location. Include hashes or exact saved paths when possible. State that the work is saved locally but not remotely protected.
+
+Do not claim work is backed up, pushed, or recoverable from another device unless evidence proves it.
+
+## User-facing update
+
+Keep it short:
+
+**Saved checkpoint:** what is complete, where it is preserved, what proof passed, and what starts next.
+
+A progress message without saved state is not a checkpoint.

adapters/chatgpt/selective-intelligence/references/first-checkpoint.md

@@ -1,70 +1,86 @@
-# First checkpoint
+# Checkpoints: intent locks and durable progress
 
-The first checkpoint prevents expensive drift when meaning or consequence justifies a lock. It is not the default first response to every request that creates or changes something.
+Selective Intelligence uses two different checkpoint types. Confusing them creates either needless approval friction or lost work.
 
-## When it fires
+## 1. Intent and authority checkpoint
 
-Use a checkpoint headed **What I understand you want** before action only when at least one condition applies:
+This checkpoint prevents expensive drift when meaning or consequence justifies a lock. It is not the default before every edit.
+
+### When it fires
+
+Use a checkpoint headed **What I understand you want** before consequential action only when:
 
 - material ambiguity remains and plausible readings lead to meaningfully different outcomes;
-- the request locks a new whole product, system architecture, migration, or cross-system contract;
+- the request locks a whole product, system architecture, migration, or cross-system contract;
 - the next action is public, irreversible, expensive, destructive, permission-changing, or exposes sensitive data; or
-- the person explicitly asks to lock intent before execution.
+- the person explicitly requests an intent lock.
 
-A clear correction, focused document change, reversible local edit, bounded feature repair, routine repository continuation, or ordinary research task stays Lean. The existence of a user, persistent file, or durable result does not by itself fire this checkpoint.
+A clear correction, bounded repair, routine continuation, reversible local edit, or ordinary research task stays Lean.
 
-## The checkpoint artifact
+### What it contains
 
-Include only the fields needed to prevent the identified drift:
+Include only what prevents the identified drift:
 
-1. **Outcome and user** — the real-world result and who must be able to use it.
-2. **Non-negotiables and prohibitions** — what must be preserved and what must not happen.
-3. **Scope and boundaries** — the complete affected surface, including explicitly excluded areas.
-4. **Outcome slices and proof** — for a whole-product lock, the bounded parts and observable evidence that make each part real.
-5. **Canonical reuse map** — existing owners to reuse or change before creating another one.
-6. **Build or action sequence** — the dependency order that avoids partial or contradictory work.
-7. **Authority split** — reversible work the AI may perform and exact consequential actions reserved for the person.
-8. **Constraint reconciliation** — material conflicts among requirements, capabilities, privacy, time, and cost.
-9. **Human-only activation steps** — only actions the person truly must take, expressed in plain language without technical setup homework.
+- real-world outcome and intended person;
+- non-negotiables and prohibitions;
+- affected and excluded surfaces;
+- observable proof;
+- canonical owners to reuse;
+- consequential authority reserved for the person.
 
-Do not inflate a narrow consequential action into a whole-product essay. For example, a publish checkpoint may need the target, artifact, visibility, and rollback implication—not nine repeated sections.
+Outside Platynum, use `APPROVE` or `CORRECT: <instruction>`. Approval unlocks only the described scope. A correction reopens affected meaning and invalidates dependent work and proof.
 
-## Information sufficiency
+Do not require approval again for every harmless step under the same boundary.
 
-Infer from active conversation, existing artifacts, authoritative evidence, and established decisions before asking. Ask one compact question only when the missing answer changes the outcome, authority, sensitive-data boundary, consequential cost, or irreversible choice and cannot be resolved safely.
+## 2. Durable progress checkpoint
 
-Whole-product locks should resolve their genuinely blocking inputs together. Later unknowns that do not block the next reversible slice stay visible; they do not prevent useful local progress. Do not trickle-ask questions that inspection can answer, and do not claim that an unverified inference is approved intent.
+This checkpoint prevents loss. It is automatic, non-blocking, and does not ask the person to approve routine preservation of already-authorized work.
 
-## Approval surface
+Create one:
 
-Present the checkpoint in short human language. Keep the complete machine-checkable record internally when the runtime needs it.
+- after each coherent completed slice;
+- before beginning the next slice;
+- before a long test, build, migration preparation, or external tool sequence;
+- before changing model, agent, context, branch, or work surface;
+- before likely timeout, capacity, or runtime boundaries;
+- whenever one completed slice or five materially changed files remain uncommitted or only in working memory;
+- immediately after a consequential external effect, with a receipt and a do-not-repeat note.
 
-- **Platynum:** the product may provide wired Approve and Correct controls bound to the current checkpoint identifier and intent hash.
-- **Outside Platynum:** use the text gate `APPROVE` or `CORRECT: <instruction>`. Do not render decorative buttons or emoji controls.
+For repository work, commit only task-owned files. Preserve unrelated changes. When remote writing is available and the person has not required local-only work, push the checkpoint to the existing task branch. Do not push directly to protected branches merely to create a savepoint. A checkpoint push never authorizes merge, release, deployment, or production mutation.
 
-Approval unlocks only the described action and scope. A correction reopens affected meaning, invalidates dependent work and proof, and creates a revised checkpoint where the trigger still applies.
+When commit or push is unavailable, write a durable resume artifact inside the project and plainly identify what remains local.
 
-## Enforcement boundary
+### Required record
 
-- Do not perform the gated consequential action before valid approval.
-- Reversible inspection and preparation may continue when they do not pre-commit the disputed choice or create an external effect.
-- Do not require approval again for every harmless step under the same approved boundary.
-- A deadline never authorizes a consequential action or false completion claim.
-- If the delivered result does not match what the person wanted, reopen understanding even when narrow tests pass.
+A durable progress checkpoint records:
 
-The SI checkpoint runtime can bind and interrupt governed session work. Do not claim it stopped arbitrary third-party model streams, tools, or workers unless product wiring proves that effect.
+- governing outcome and prohibitions;
+- completed and verified work;
+- changed but unverified work;
+- repository, branch, base revision, and current revision or containing commit;
+- saved files and their ownership;
+- tests and evidence;
+- external effects and receipts;
+- actions that must not be repeated;
+- next safe action;
+- remaining authority requirement, if any.
 
-## Relationship to execution lanes
+A progress message, chat summary, or “still working” update without saved state is not a checkpoint.
 
-Lean work normally has no checkpoint. Guarded work uses one only when a trigger above is present. Council work commonly includes one because its selection conditions often involve ambiguity or consequence, but Council status alone is not a reason to repeat already settled approval.
+## Resume rule
 
-The checkpoint locks meaning or authority; it does not require seven roles, a Start Pack, a queue, or a Resume Packet. Those artifacts are separate tools used only when the selected workflow genuinely needs them.
+Resume from the checkpoint, actual source state, and external receipts. Never restart from persuasive conversation memory.
 
-## Measure
+1. Inspect repository, branch, revision, and dirty changes.
+2. Compare them with the checkpoint.
+3. Verify external effects before retrying.
+4. Continue from the first unproved transition.
+5. Create a new checkpoint after the recovered slice.
 
-Track two outcomes:
+Unknown external outcomes are never assumed safe to repeat.
+
+## Enforcement boundary
 
-- **avoidable checkpoint rate** — clear reversible tasks stopped for approval without a trigger; target zero;
-- **correction rounds to correct consequential checkpoint** — user corrections needed before a triggered lock matches intent; target zero.
+Intent checkpoints protect meaning and authority. Progress checkpoints protect continuity. Neither replaces the other.
 
-Both matter. A gate that catches costly drift is useful; a gate placed before every harmless edit is token and interaction waste.
+A runtime may enforce both, one, or neither. Do not claim a checkpoint stopped a third-party worker, committed files, or pushed a branch unless the actual wiring and evidence prove it.