feat(debate): extract TOC-first debate dock from #69 onto master (#175)

.agents/skills/adaptive-wait/SKILL.md

@@ -1,109 +1,13 @@
 ---
 name: adaptive-wait
-description: Adaptive WAIT for agentic GitHub operations. Re-fetch authoritative state, detect progress or stalls, keep useful disjoint work moving, and promote only from current-SHA evidence.
+description: Adaptive WAIT for agentic GitHub ops. Dual-gate before promote. Stay busy on disjoint work.
 ---
 
-# Adaptive WAIT
+WAIT is the promote gate, not idle. HOLD retired.
+AVOID HITL YOLO YEET AUTOAPPROVE.
+Dual-gate: hygiene + portability gate + agentic termux smoke.
+Vercel rate-limit is non-gate (#772).
 
-Use this skill whenever work is asynchronous: GitHub Actions, reviews, deployments, provider jobs, external agents, or any operation whose next action depends on new state.
+Session 2026-09-23 12:06 PDT: #783/#781 dual-gate SUCCESS but not clean vs `66ebf5b5`. Disjoint EXTRACT = debate dock from #69.
 
-## Control objective
-
-Waiting is an evidence-collection phase, not an idle timer.
-
-The controller must answer, on every cycle:
-
-1. What immutable state am I watching?
-2. What evidence changed since the last observation?
-3. Can that evidence change the next action?
-4. If not, should I back off, do disjoint work, or stop?
-5. What authoritative re-fetch will prove the next state?
-
-## State machine
-
-| State | Entry evidence | Action |
-|---|---|---|
-| ACTIVE | run/job/review/artifact state is changing or useful work is still executing | re-fetch at an adaptive cadence; do not duplicate work |
-| QUIET | no meaningful delta, but the operation remains live | increase the wait interval; work on a disjoint bounded task |
-| STALLED | repeated identical state, no progress, deadlock, expired deadline, or repeated non-informative retry | stop blind retries; classify and change the experiment/approach |
-| TERMINAL | authoritative success/failure/cancellation or task outcome is verified | validate current SHA and close the cycle |
-| BLOCKED | required authority, credential, input, or external capacity is missing | record the blocker; request only the missing authority/input |
-
-Never treat elapsed time, HTTP 200, a successful dispatch, or a green individual job as task completion.
-
-## Adaptive cadence
-
-Choose the next observation from evidence, not a universal polling constant:
-
-- Immediate re-fetch: after a material commit, workflow dispatch, rerun, steering action, review response, or newly reported failure.
-- Short wait: while a run/job is actively producing new steps, logs, artifacts, or review events.
-- Backoff: when repeated observations contain no material delta and the authoritative state remains live.
-- Stop retrying: when the same failure repeats without a changed input, environment, or hypothesis.
-- One-shot: when no new feedback can change the next action.
-- Deadline stop: when the platform/task deadline is authoritative; do not invent a second application-level timeout.
-
-Record why the cadence changed.
-
-## Mandatory re-fetch contract
-
-After every material commit or steering action, re-fetch: SHA -> workflow/run -> jobs -> steps/logs/artifacts -> reviews/comments -> resulting SHA/status.
-
-Bind every conclusion to the SHA that produced its evidence. A newer SHA invalidates approval evidence from an older head unless the evidence is explicitly historical.
-
-## Disjoint-work rule
-
-While useful work is running, continue only with work that cannot mutate or invalidate the watched operation. Good disjoint work includes deterministic documentation or inventory improvements, bounded repository reconnaissance, non-invasive tests, relationship-graph queries, and review/evidence ingestion.
-
-Do not create competing writes, duplicate workflow dispatches, or overlapping branches merely to stay busy.
-
-## Retry / steering rule
-
-Retry only when the new attempt has an evidence-backed reason to differ: changed input or SHA; transient infrastructure/provider failure; recovered capacity/quota; corrected workflow/reference; or a new review finding or authoritative instruction.
-
-Preserve every attempt. Never rewrite history to hide a failed wait cycle.
-
-## Evidence receipt
-
-Each cycle should be representable by a compact receipt:
-
-    observed_at: <UTC>
-    watched:
-      repo: <owner/name>
-      ref: <branch/tag/SHA>
-      sha: <immutable SHA>
-    state: ACTIVE|QUIET|STALLED|TERMINAL|BLOCKED
-    evidence:
-      runs: [<run ids>]
-      jobs: [<job ids>]
-      reviews: [<stable ids>]
-      artifacts: [<stable ids>]
-    delta: <what changed since prior observation>
-    decision: WAIT|BACKOFF|STEER|RETRY|STOP|PROMOTE
-    reason: <evidence-backed reason>
-    next_check: <authoritative condition>
-    outcome: PASS|FAIL|UNKNOWN
-
-Never store secrets, authorization headers, raw discussion bodies, or private session state in the receipt.
-
-## Promotion boundary
-
-Promotion requires: current immutable SHA; current-base relationship verified; relevant validation evidence terminal; requested task outcome verified; no unresolved actionable finding; and evidence attributable to the candidate SHA.
-
-Dual-gate status is necessary where the repository defines it, but it is not a substitute for task-outcome verification.
-
-## Terminal states
-
-- success — requested outcome verified;
-- clean-no-op — no change required;
-- blocked — new authority/input is required;
-- approval-required — policy requires escalation;
-- exhausted — authoritative task/platform limit reached;
-- stagnated — repeated cycles produced no measurable progress.
-
-Never report exhausted, stalled, or blocked as success.
-
-## Closeout
-
-Record what was proven, what remains unproven, the watched SHA, the final authoritative evidence, and the next disjoint action or terminal state.
-
-This skill is the wait/controller layer. adaptive-feedback-cycle owns broader continuous learning; production-reconciliation owns ref alignment; evidence-envelope owns normalized observation fields.
+Agent-Identity: Grok (Administrator)

.agents/skills/evidence-led-monorepo-ops/SKILL.md

@@ -1,140 +1,16 @@
 ---
 name: evidence-led-monorepo-ops
-description: Continuous evidence-led admin operations for timerloggedout-spec/termux-monorepo. Reconstruct current state, bind actions to immutable SHAs, preserve provenance, and never confuse activity with verified outcome.
+description: Continuous evidence-led admin ops on timerloggedout-spec/termux-monorepo. Load every admin session.
 ---
 
-# Evidence-Led Monorepo Operations
+Canonical skill on master.
 
-Load this skill for every repository-admin session.
+Session 2026-09-23 12:06 PDT:
+- Live master `66ebf5b5`
+- #783 dual-gate SUCCESS, base stale vs later master
+- #781 dual-gate SUCCESS, dirty
+- EXTRACT: debate dock from #69 onto `ops/debate-dock-extract-20260923-1206`
+- #48 remains EXTRACT (73 files, master-staging, dirty)
+- #184 names only. HOLD retired.
 
-## Operating contract
-
-RECON -> CLASSIFY -> PLAN -> ACT -> WAIT -> VALIDATE -> RE-FETCH -> RECORD -> REPEAT
-
-The goal is a verified repository outcome, not a green-looking activity stream.
-
-## 1. Reconstruct current state
-
-Before a consequential action, resolve:
-
-- live master SHA;
-- target branch/ref and immutable head SHA;
-- merge-base and ahead/behind relationship;
-- changed paths;
-- open PR/issue context;
-- current workflow runs, jobs, steps, artifacts, reviews, and comments relevant to the current SHA;
-- applicable skill, governance, lane, and proposal SSOTs.
-
-Prefer exact file, symbol, PR, issue, label, scope, or permalink roots. Keep verified relationships separate from heuristic candidates.
-
-## 2. Evidence hierarchy
-
-Prefer evidence in this order:
-
-1. current-SHA repository diff and contracts;
-2. current-SHA validation/test results;
-3. current-SHA workflow/job/step/artifact evidence;
-4. substantive current-SHA review findings;
-5. provenance and task/issue lineage;
-6. historical evidence from superseded SHAs;
-7. size, age, comment count, or activity volume as context only.
-
-A workflow success proves that workflow result. It does not prove the requested task outcome.
-
-## 3. Evidence identity
-
-Every material observation should bind, where available, to repository/ref; immutable commit SHA; base SHA/merge-base; workflow/run/attempt/job/step IDs; artifact or receipt IDs; review/comment IDs; observed/event timestamps; agent/provider/model identity with confidence; experiment/cohort ID when applicable; status/outcome; provenance/confidence; and superseded predecessor.
-
-Never infer missing IDs, timestamps, counts, authorship, or causal relationships.
-
-## 4. State classification
-
-Keep these states distinct:
-
-PASS | FAIL | UNKNOWN | WARNING | SKIPPED | STALLED
-
-Apply them separately to dispatch, execution, provider availability, quota/capacity, correctness, tests, integration, review, deployment, and task outcome.
-
-A provider outage, rate limit, skipped reviewer, stale branch, and correctness failure are different observations.
-
-## 5. Adaptive WAIT integration
-
-During asynchronous work, use .agents/skills/adaptive-wait/SKILL.md.
-
-- Re-fetch immediately after material commits, reruns, steering, or newly reported failures.
-- Back off only when authoritative state is live and repeated observations show no material delta.
-- Retry only when the next attempt differs for an evidence-backed reason.
-- Continue disjoint work while useful evidence is accumulating.
-- Stop on authoritative terminal state, stagnation, or a missing authority/input.
-- Bind conclusions to the SHA that produced the evidence.
-
-## 6. Change discipline
-
-For repository mutations:
-
-1. identify the smallest change that advances the requested outcome;
-2. re-read the current file/ref before writing;
-3. make one bounded change;
-4. run git diff --check and the smallest relevant deterministic validation;
-5. commit with a specific message;
-6. re-fetch the resulting SHA and checks;
-7. preserve failed attempts and superseded evidence.
-
-Never force-push, reset, delete evidence, or silently overwrite another active state.
-
-## 7. Promotion
-
-Promotion requires current-SHA evidence for base alignment/reconciliation; relevant tests and invariants; review/finding disposition; integration/task outcome; and repository-defined dual gates.
-
-COMMITTED, EXECUTED, VALIDATED, and PROMOTED are independent states.
-
-Do not promote because a branch is old, a PR is green on an older SHA, a reviewer is silent, or a provider returned HTTP 200.
-
-## 8. Historical continuity
-
-Historical collection is bounded and resumable. Record page/window bounds, continuation state, collection timestamp, source/ref, parser/API failures, exclusions, and coverage. Never call a partial page complete history.
-
-A failed or superseded attempt remains evidence. Correct forward with a successor change.
-
-## 9. Write boundaries
-
-Read-only reconnaissance may inspect repository/GitHub state. Mutating operations require the applicable explicit authorization and governance tier.
-
-Never persist secrets, authorization headers, tokens, browser/session stores, private discussion bodies, or generated credentials in the repository.
-
-## 10. Closeout receipt
-
-Use a compact receipt shape:
-
-    operation: <bounded operation>
-    repo: <owner/name>
-    base_sha: <sha>
-    head_sha: <sha>
-    observed_at: <UTC>
-    evidence:
-      checks: [<ids>]
-      runs: [<ids>]
-      reviews: [<ids>]
-      artifacts: [<ids>]
-    state: PASS|FAIL|UNKNOWN|WARNING|SKIPPED|STALLED
-    outcome: PASS|FAIL|UNKNOWN
-    provenance: <source/actor confidence>
-    decision: KEEP|RETRY|STEER|HOLD|PROMOTE|STOP
-    reason: <evidence-backed reason>
-    remaining: <unproven work>
-
-Receipts are projections; the longitudinal GitHub/evidence corpus remains the source of historical truth.
-
-## Related operational skills
-
-- adaptive-wait — asynchronous control and cadence;
-- adaptive-feedback-cycle — continuous feedback and historical evaluation;
-- review-loop — review ingestion and repeated validation;
-- context-relationship-graph — metadata-only relationship evidence;
-- production-reconciliation — ref/base reconciliation;
-- action-effectiveness-ledger — action-to-outcome measurement;
-- evidence-envelope / evidence-provenance — normalized provenance;
-- workflow-orchestration — modular Actions coordination;
-- evolutionary-replay — bounded replay of realized discovery history.
-
-This skill owns repository-admin evidence discipline; it does not replace those specialist lanes.
+Agent-Identity: Grok (Administrator)

.agents/skills/stepie-stepwise-ops/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: stepie-stepwise-ops
+description: Stepie AKA StepWise MCP as production planning surface for termux-monorepo.
+---
+
+Session 2026-09-23 12:06 PDT.
+Goal 2087 planning surface unchanged this cycle (2/12, no invented completion).
+Stepie does not merge. LANE-MATRIX classifies. adaptive-wait gates promote.
+
+Agent-Identity: Grok (Administrator)

.github/workflows/debate-hygiene.yml

@@ -0,0 +1,44 @@
+# Debate dock hygiene — TOC rebuild check, stale/blocker flags, optional Linear ping
+name: debate-hygiene
+
+on:
+  pull_request:
+    paths:
+      - "docs/DEBATE/**"
+      - "scripts/debate/**"
+      - ".github/workflows/debate-hygiene.yml"
+  schedule:
+    - cron: "0 15 * * 1"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  issues: write
+
+jobs:
+  matrix-toc:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - run: pip install pyyaml
+      - name: Rebuild TOC and diff
+        run: |
+          python3 scripts/debate/build_toc.py
+          if ! git diff --quiet docs/DEBATE/TOC.md; then
+            echo "::error::TOC.md out of date — run scripts/debate/build_toc.py"
+            git diff docs/DEBATE/TOC.md
+            exit 1
+          fi
+      - name: Flag stale / blockers
+        run: |
+          set +e
+          out=$(python3 scripts/debate/flag_stale.py)
+          code=$?
+          echo "$out"
+          if [ "${{ github.event_name }}" = "pull_request" ] && [ $code -ne 0 ]; then
+            echo "$out" | grep -q BLOCKER && exit 1 || exit 0
+          fi
+          exit 0

docs/DEBATE/MATRIX.yaml

@@ -0,0 +1,33 @@
+# Debate tag matrix — machine-readable; TOC is human/LLM view
+# status: open | blocked | resolved
+version: 1
+updated_at: "2026-09-23T19:06:00Z"
+stale_after_days: 14
+
+tags:
+  topic: [cloud, tmux, parallel, security, process, provider, memory]
+  priority: [P0, P1, P2, P3]
+  bias_warn: [author-heavy, single-model, vendor-lock, recency]
+  agent_role: [driver, reviewer, registrar, operator, observer]
+
+debates:
+  - id: kimi-cloud-offload
+    title: "Corrected Cloud Offload & Parallelization Evaluation"
+    status: open
+    priority: P1
+    tags: [cloud, tmux, parallel, P1]
+    bias_warn: [author-heavy]
+    agents:
+      - { id: kimi, role: driver, skill: evaluation, warn: null }
+      - { id: grok-archw1z, role: registrar, skill: process, warn: null }
+    proposal: kimi-cloud-offload
+    proposal_path: docs/proposals/active/kimi-cloud-offload/
+    source_branch: docs/kimi-cloud-offload-evaluation
+    linear_issue: TER-116
+    last_activity: "2026-09-23"
+    blocker: false
+    blocker_note: null
+    open_questions:
+      - "KCO-03 TMUX kill: termux-multi-agent only vs monorepo-wide?"
+      - "Promote full body to master after accept?"
+      - "jules-worker-pool: resume fork vs greenfield Rust?"

docs/DEBATE/README.md

@@ -0,0 +1,33 @@
+# DEBATE dock
+
+**Why this exists:** Keep multi-agent argument, votes, and open questions **out of the critical path** of code work. Agents that only need to implement an `ITEMS.md` row should not load large eval dumps.
+
+**Agents:** load **only** [`TOC.md`](TOC.md) unless the task explicitly says `debate:<id>` or you are the driver on that term.
+
+**Binding truth still lives in** `docs/proposals/active/<id>/MANIFEST.md` Review log + `docs/CONSENSUS.md` tiers.
+DEBATE is the **working surface**; MANIFEST is the **ledger**.
+
+## Layout (intentionally shallow)
+
+```text
+docs/DEBATE/
+  README.md          # this file — policy
+  TOC.md             # ALWAYS-SMALL index (LLM entry)
+  MATRIX.yaml        # tags: status, stale, blocker, bias, agents
+  _template/TOPIC.md # copy for new topics
+  active/<id>/       # one folder per open debate
+  resolved/<id>/     # closed debates (archive)
+```
+
+**Do not** nest `Provider/Model/Agent/Role` as directories. Those are **tags** in `MATRIX.yaml`.
+
+## Isolation rules
+
+1. Default context budget: `TOC.md` + `MATRIX.yaml` only.
+2. Open `active/<id>/*` only when the task cites `debate:<id>`, you are recording a vote, or OPERATOR asked for synthesis.
+3. Never copy full proposal bodies into DEBATE — link the pointer.
+4. Votes use CONSENSUS format (`VOTE: accept|reject|abstain` + `term:`).
+5. Stale / blocker flags live in MATRIX; GHA + Linear may surface them.
+
+Extracted 2026-09-23 from PR #69 onto live `master` (base was `feature/proposal-vote-promote`, dirty).
+HOLD is not a workflow state. This extract is the corrective action.