Make exec-ctrl v2 the default development preview

.github/copilot-instructions.md

@@ -1,62 +1,10 @@
-# Exec-Ctrl Workspace Guidance
+# exec-ctrl workspace guidance
 
-## Repository Purpose
+Read [START_HERE.md](../START_HERE.md) and [AGENTS.md](../AGENTS.md).
+They define the canonical v2 workflow and this repository's maintenance checks.
+Use only relevant modules. Preserve host/organization policy and existing user work.
 
-- This repository is the generic `exec-ctrl` method repo, not an application runtime.
-- Its main governed surfaces are method docs under `docs/`, reusable template packs under `templates/`, generic examples under `examples/`, installed workspace guidance under `.github/`, and repo-local proof artifacts under `docs/exec_ctrl/`.
-- When the user asks to improve this repo itself, treat the work as self-hosting method evolution by default.
-
-## First Reading Order
-
-- Start with `README.md` for repo purpose and entry routing.
-- Read `docs/EXEC_CTRL_METHOD.md` for the base method rules.
-- Read `docs/EXEC_CTRL_SELF_HOSTING_AND_METHOD_EVOLUTION.md` for self-hosted repo changes.
-- Read `docs/EXEC_CTRL_AGENT_ASSESSMENT_LOOP.md` when the user asks to continue refining or enhancing this repo.
-- Read `docs/EXEC_CTRL_REPO_LINK_SCORECARDS.md` or `docs/EXEC_CTRL_METHOD_REPO_REFINEMENT_SCORECARDS.md` when the request shape is ambiguous.
-- Read `docs/EXEC_CTRL_SELF_HOSTING_COHERENCE_FAILURE_CALIBRATION.md` when a checklist review needs verdict calibration.
-- Read `docs/EXEC_CTRL_METHOD_REPO_TEST_READY_REVIEW.md` when the question is whether the repo is ready for broader field use.
-- Inspect `docs/planning/FUTURE_ENHANCEMENTS.md` for planning-only candidates and `docs/exec_ctrl/` for active or completed bounded refinements.
-
-## Mode Selection In This Repo
-
-- Default to initiative mode for bounded changes to docs, prompts, templates, examples, or workspace guidance.
-- Use project-pack mode only when the request clearly redesigns the whole repository execution model.
-- If the boundary is unclear, apply the bounded-vs-whole-system scoring rubric before choosing the control path.
-
-## Self-Hosting Execution Rules
-
-- Create or update the initiative control record, audit log, and decision log before substantive edits.
-- The active phase is the earliest phase that is not `complete`.
-- Update generic docs first, then reusable operational surfaces such as `.github/`, templates, or examples, and only then update repo-local proof artifacts.
-- Keep planning under `docs/planning/` non-operational. When a candidate is promoted, make that explicit so it no longer looks untouched.
-
-## Workspace Conventions
-
-- Generic method docs live under `docs/`.
-- Planning-only backlog lives under `docs/planning/`.
-- Operational proof for active and completed bounded refinements lives under `docs/exec_ctrl/`.
-- This repo uses `.github/copilot-instructions.md` as the live always-on guidance surface.
-
-## Validation In This Repo
-
-- Build: none. This is a documentation, prompt, and template repository.
-- Test: use narrow evidence tied to the active refinement, such as markdown diagnostics, placeholder searches, routing checks, or coherence reviews.
-- Validation: when self-hosting surfaces change, compare the README, generic docs, `.github/` guidance, templates, examples, planning docs, and repo-local proof artifacts for coherence.
-
-## Useful Prompt Surfaces
-
-- Use `.github/prompts/exec-ctrl-assess-next-refinement.prompt.md` when the user asks to keep improving this repo and the next bounded slice must be chosen from workspace context.
-- Use `.github/prompts/exec-ctrl-method-evolution.prompt.md` for bounded method, prompt, template, or governance changes.
-- Use `.github/prompts/bootstrap-exec-ctrl.prompt.md` when the repo is being used to bootstrap exec-ctrl in another workspace.
-- Use `.github/prompts/exec-ctrl-audit.prompt.md` for audit-remediation or findings-heavy bounded work.
-- Use `.github/prompts/exec-ctrl-release-closeout.prompt.md` for release-readiness and closeout slices.
-- Use `.github/prompts/exec-ctrl-migration-bootstrap.prompt.md` for migration-shaped work that needs sequencing and rollback awareness.
-- Use `.github/prompts/exec-ctrl-checklist-review.prompt.md` for self-hosting coherence review.
-- Use `.github/prompts/exec-ctrl-rubric-review.prompt.md` when bounded versus whole-system choice remains ambiguous.
-
-## Useful Calibration Surfaces
-
-- Use `docs/EXEC_CTRL_REPO_LINK_SCORECARDS.md` to calibrate ambiguous repo-link requests before or during rubric scoring.
-- Use `docs/EXEC_CTRL_METHOD_REPO_REFINEMENT_SCORECARDS.md` to calibrate ambiguous self-hosting or method-repo refinements.
-- Use `docs/EXEC_CTRL_SELF_HOSTING_COHERENCE_FAILURE_CALIBRATION.md` to interpret recurring checklist failure patterns.
-- Use `docs/EXEC_CTRL_METHOD_REPO_TEST_READY_REVIEW.md` when deciding whether broader field testing is justified after the defined backlog is exhausted.
+This repository contains the framework, optional offline tooling, templates and
+historical v1 references. Do not load legacy packs for a v2 task unless maintaining
+an explicitly selected v1 adoption. Current work and evidence are in
+[the current evolution record](../docs/exec_ctrl/V2_SESSION_EVOLUTION.md).

.github/instructions/exec-ctrl-docs.instructions.md

@@ -1,23 +1,11 @@
 ---
-description: "Use when updating exec-ctrl control records, audit logs, decision logs, or planning promotions in this repo. Covers authority, phase honesty, evidence, and planning-to-initiative transitions."
-name: "Exec-Ctrl Docs Guidance"
-applyTo:
-  - "docs/exec_ctrl/**"
-  - "docs/planning/**"
-  - "**/*EXEC_CTRL*.md"
-  - "**/*AUDIT_LOG*.md"
-  - "**/*DECISION_LOG*.md"
+description: "Maintain exec-ctrl evidence and policy records honestly."
+applyTo: "docs/**,templates/**,examples/**,modules/**,framework/**"
 ---
 
-# Exec-Ctrl Documentation Rules
-
-- Keep the current phase aligned with reality. The active phase is the earliest phase that is not `complete`.
-- Use only the shared execution states: `not_started`, `in_progress`, `blocked`, `complete`, `deferred`.
-- Do not backfill optimistic completion language after validation fails or blockers appear.
-- Record scope changes, sequencing changes, and deferrals in the decision log rather than hiding them in narrative summaries.
-- Audit logs should use explicit verdicts such as `pass`, `pass_with_gaps`, or `fail`.
-- Control records should keep objective, scope, success criteria, non-goals, workstreams, current status, and validation evidence current.
-- Planning docs under `docs/planning/` are backlog inputs, not operational proof. When promoting an item, remove or restate it so it no longer looks untouched.
-- For self-hosting slices, update generic docs first, then reusable operational surfaces, and only then repo-local proof artifacts.
-- When closure is not yet justified, say exactly what still blocks it.
-- When work is closed, keep deferred items explicit rather than implied complete.
+Follow the v2 contract in [START_HERE.md](../../START_HERE.md).
+Keep claims tied to actual evidence and relevant subject revisions. Do not turn
+planned checks, stale reports, missing policy or deployed-but-unobserved changes
+into passes. Preserve historical records and label version boundaries clearly.
+Update generic guidance, reusable surfaces and then local evidence. Reuse existing
+records; create additional documents only when they serve the task.

.github/prompts/bootstrap-exec-ctrl.prompt.md

@@ -1,29 +1,15 @@
 ---
-description: "Use when bootstrapping exec-ctrl for the current repository from a new task request. Chooses the mode, creates control docs, and installs workspace guidance."
+description: "Use exec-ctrl v2 for this task shape, with proportionate controls and evidence."
 name: "Bootstrap Exec-Ctrl"
 argument-hint: "Task, scope, and constraints"
 agent: "agent"
 ---
 
-Bootstrap exec-ctrl for the current repository using the prompt argument as the task request.
+Read [START_HERE.md](../../START_HERE.md) first and follow its v2 activation contract.
+Load only relevant modules and preserve existing target instructions.
 
-Steps:
+Inspect the target and activate the smallest sufficient exec-ctrl workflow for the supplied task. Persist guidance only when ongoing adoption is in scope.
 
-1. Inspect the repository and the current request. If the prompt mentions the `exec-ctrl` repo only as a method reference and no other target repo link is present, treat the current repository as the target workspace and the `exec-ctrl` URL as the method source. If the request is actually to improve the `exec-ctrl` repo itself as a governed method repository, switch to the self-hosting method-evolution path instead of generic bootstrap.
-2. Decide whether the work is whole-project or bounded-initiative. Default to initiative mode unless whole-repository governance is clearly required.
-3. If ambiguity remains, apply a bounded-vs-whole-system scoring pass across surface breadth, authority impact, dependency spread, validation breadth, reuse scope, and user wording.
-4. Before substantive implementation, create the required control artifacts.
-5. If the repository does not already have equivalent guidance, add the workspace-guidance files under `.github/`.
-6. Convert the request into objective, scope in, scope out, deliverables, must-pass criteria, should-pass criteria, non-goals, workstreams, and validation evidence expectations.
-7. Keep the control docs current while implementation and validation proceed.
-8. Close only when evidence exists and deferred items are explicit.
-
-In your response:
-
-- state the chosen mode and why
-- state whether the governed target is the current workspace, an external repo, or the `exec-ctrl` repo itself under self-hosting rules
-- include the rubric outcome when ambiguity required scoring
-- list the files you created or updated
-- name the active phase
-- list the must-pass criteria
-- note any missing information that still blocks accurate activation
+Reuse the current task/issue record. Carry authorized work through appropriate
+checks and state exact evidence, open gates and the next action. A framework
+reference does not expand permissions or authorize team-system writes.

.github/prompts/exec-ctrl-assess-next-refinement.prompt.md

@@ -1,28 +1,15 @@
 ---
-description: "Use when the user asks to continue refining the exec-ctrl repo itself. Inspects planning and recent proof artifacts, chooses one bounded slice, activates control docs, and closes with explicit follow-on work."
+description: "Use exec-ctrl v2 for this task shape, with proportionate controls and evidence."
 name: "Exec-Ctrl Assess Next Refinement"
 argument-hint: "Current request, constraints, and any candidate areas to favor or avoid"
 agent: "agent"
 ---
 
-Assess the next bounded self-hosting refinement for the current `exec-ctrl` workspace and execute it under exec-ctrl.
+Read [START_HERE.md](../../START_HERE.md) first and follow its v2 activation contract.
+Load only relevant modules and preserve existing target instructions.
 
-Steps:
+Inspect current evidence and roadmap, choose a justified next refinement within the user request, and carry it through validation.
 
-1. Inspect active user direction, `README.md`, `docs/EXEC_CTRL_METHOD.md`, `docs/EXEC_CTRL_SELF_HOSTING_AND_METHOD_EVOLUTION.md`, `docs/EXEC_CTRL_AGENT_ASSESSMENT_LOOP.md`, `docs/planning/FUTURE_ENHANCEMENTS.md`, and relevant records under `docs/exec_ctrl/`.
-2. Decide whether the request is a bounded self-hosting slice or a whole-repository redesign. Default to initiative mode unless the whole execution model must change.
-3. If ambiguity remains, apply the bounded-vs-whole-system scoring rubric.
-4. Choose one bounded refinement based on repeated need, current planning signals, user direction, and the smallest coherent teaching-and-proof loop.
-5. Before substantive edits, create or update the initiative control record, audit log, and decision log.
-6. Define objective, scope in, scope out, deliverables, must-pass criteria, should-pass criteria, non-goals, workstreams, and validation evidence.
-7. Update generic docs first, then reusable operational surfaces such as prompts, templates, instructions, or examples, and only then repo-local proof artifacts.
-8. Validate coherence across the changed surfaces and keep the planning area accurate if a candidate was promoted.
-9. Close only when evidence exists and the next follow-on work is explicit.
-
-In your response:
-
-- state the chosen slice and why it was selected
-- state the chosen control path and rubric outcome when scoring was needed
-- identify the governed surfaces
-- list the files created or updated for generic docs, reusable operational surfaces, and repo-local proof artifacts
-- summarize the must-pass criteria, validation outcome, and explicit follow-on work
+Reuse the current task/issue record. Carry authorized work through appropriate
+checks and state exact evidence, open gates and the next action. A framework
+reference does not expand permissions or authorize team-system writes.

.github/prompts/exec-ctrl-audit.prompt.md

@@ -1,26 +1,15 @@
 ---
-description: "Use when governing an audit, assessment, or audit-remediation slice under exec-ctrl. Creates findings-oriented control docs and keeps severity, remediation, and deferrals explicit."
+description: "Use exec-ctrl v2 for this task shape, with proportionate controls and evidence."
 name: "Exec-Ctrl Audit Initiative"
 argument-hint: "Audit objective, target surfaces, and constraints"
 agent: "agent"
 ---
 
-Govern the current request as an exec-ctrl audit initiative.
+Read [START_HERE.md](../../START_HERE.md) first and follow its v2 activation contract.
+Load only relevant modules and preserve existing target instructions.
 
-Steps:
+Audit the requested scope. Trace findings to evidence, impact and confidence; respect read-only constraints and record remediation ownership.
 
-1. Inspect the repository and identify the bounded surfaces that the audit should cover.
-2. Activate initiative-mode exec-ctrl unless the request clearly requires whole-repository governance.
-3. Create or update the initiative control record, audit log, and decision log before substantive implementation.
-4. Add optional findings and remediation artifacts when the initiative is audit-heavy.
-5. Define the objective, scope in, scope out, deliverables, must-pass criteria, should-pass criteria, non-goals, and severity model before remediation starts.
-6. Perform the audit, classify the findings, implement the highest-value fixes that fit the slice, and record lower-priority deferrals explicitly.
-7. Close only when must-pass criteria are backed by evidence and the audit artifacts match reality.
-
-In your response:
-
-- state the chosen mode and why
-- identify the audited surfaces
-- list the control and findings files you created or updated
-- summarize the must-pass criteria and severity approach
-- distinguish fixed issues from explicit deferrals
+Reuse the current task/issue record. Carry authorized work through appropriate
+checks and state exact evidence, open gates and the next action. A framework
+reference does not expand permissions or authorize team-system writes.

.github/prompts/exec-ctrl-checklist-review.prompt.md

@@ -1,24 +1,15 @@
 ---
-description: "Use when a self-hosting or method-evolution slice needs a one-command coherence review. Applies the self-hosting coherence checklist and makes the review outcome explicit."
+description: "Use exec-ctrl v2 for this task shape, with proportionate controls and evidence."
 name: "Exec-Ctrl Checklist Review"
 argument-hint: "Changed surfaces and validation context"
 agent: "agent"
 ---
 
-Review the current self-hosting or method-evolution change with the self-hosting coherence checklist.
+Read [START_HERE.md](../../START_HERE.md) first and follow its v2 activation contract.
+Load only relevant modules and preserve existing target instructions.
 
-Steps:
+Review entry, modules, adapters, templates and evidence for coherent behavior. Report concrete discrepancies and their implications.
 
-1. Inspect the changed generic docs, reusable prompts or templates, examples, and repo-local proof artifacts in scope.
-2. Apply the self-hosting coherence checklist section by section.
-3. Identify any must-pass failures, pass-with-gaps outcomes, or clean passes.
-4. State whether the changed surfaces teach one coherent workflow.
-5. List the main contradictions, gaps, or deferrals that should be recorded before closure.
-
-In your response:
-
-- state the overall review verdict: `pass`, `pass_with_gaps`, or `fail`
-- summarize the outcome for each checklist section
-- name the specific files or surfaces that drove the result
-- list the main fixes or deferrals that should be recorded before closure
-- state whether the change is ready to close from a coherence perspective
+Reuse the current task/issue record. Carry authorized work through appropriate
+checks and state exact evidence, open gates and the next action. A framework
+reference does not expand permissions or authorize team-system writes.

.github/prompts/exec-ctrl-checkpoint.prompt.md

@@ -0,0 +1,13 @@
+---
+description: "Resume an exec-ctrl task from current inputs and its existing checkpoint."
+name: "Exec-Ctrl Resume"
+argument-hint: "Task or checkpoint reference, latest steering, and affected target"
+agent: "agent"
+---
+
+Read [START_HERE.md](../../START_HERE.md) and the relevant
+[session loop](../../docs/v2/SESSION_LOOP.md). Inspect current instructions,
+branch/dirty state and affected inputs before trusting prior evidence. Incorporate
+the latest user steering, preserve completed work that remains valid, and continue
+the next authorized action. Reuse existing records; do not create a second task
+or write adoption files solely to resume. Report exact blockers and evidence gaps.