@event4u/agent-config 9.8.0 → 9.10.0

package/docs/deploy/team-deployment-posture.md

@@ -1,111 +0,0 @@
-# Team Deployment Posture
-
-> **Status** · v0 · 2026-05-24. Phase 9 of
-> [`road-to-employee-product-and-external-proof.md`](../../agents/roadmaps/archive/road-to-employee-product-and-external-proof.md).
-> Codifies what is shipped today, what stays cancelled-with-reason,
-> and what is reachable via existing primitives — so feedback rounds
-> 9+ asking "team SSO when?" land on a written answer.
-
-## Where agent-config sits today
-
-| Surface | Status |
-|---|---|
-| Single-user workspace | **Shipped** (Phases 4–7 of this roadmap, single-user / single-machine) |
-| Small-team via shared overrides | **Shipped** (existing primitives — see [`small-team-recipe`](small-team-recipe.md)) |
-| Organization mode (SSO, central policy, OAuth connectors) | **Cancelled-with-reason** — tracked in successor roadmap stubs |
-
-## Shipped — what works today
-
-The phases below this section, once implemented, deliver:
-
-- A daily workspace browser tab (Phase 4) — per-user, local-only.
-- Document workflows (Phase 5) — offer / mail / memo / brief /
-  video-script with local revision history and export.
-- Plain explain mode (Phase 6) — role-aware translation of the
-  memory-trust surface.
-- Local analytics (Phase 7) — top prompts, completion rate,
-  session length; never leaves the machine.
-- At-rest encryption (Phase 8) — AES-256-GCM with OS keyring,
-  default on from workspace v1.0.
-
-All of these run on **one machine, one OS user, one workspace**. No
-remote backend. No shared state. No sign-on screen.
-
-## Reachable via existing primitives — small-team mode
-
-A team of 3–10 people can use the package collaboratively today
-without any code change, by leaning on three existing primitives:
-
-| Primitive | What it gives the team |
-|---|---|
-| `agents/overrides/` repo, shared via git | Shared prompts, role experiences, glossaries, skills overrides |
-| Knowledge ingestion from a shared NAS / SharePoint mount | Each user runs `/knowledge:ingest` against the same mount; per-user index, same content |
-| Manual prompt-pack distribution via npm `@event4u/agent-config-<team>` | Team publishes a thin pack of role experiences as a private npm package |
-
-The recipe lives in [`small-team-recipe`](small-team-recipe.md).
-
-## Cancelled-with-reason — organization mode
-
-The prior archived `road-to-internal-ai-os-deployment.md` Phases 2–5
-were cancelled under Hard-Floor (no real first customer, no audit
-funding, no recruit-session signal). Phase 9 **does not reactivate
-them**. The cancellations stand:
-
-| Cancelled surface | Reason | Successor roadmap (stub) |
-|---|---|---|
-| **SSO / OIDC sign-on** | No customer requires it. Auth surface is auth-adjacent — `engineering-safety-floor` Hard-Floor on adoption without a funded security audit. | `road-to-team-sso.md` |
-| **Central policy enforcement** | Multi-tenant policy without SSO is a half-solution. Wait for SSO. | `road-to-central-policy.md` |
-| **Team-shared overrides server** | Shared-overrides-via-git already works for the small-team case. Server only makes sense once the org-mode threshold is reached. | `road-to-team-context.md` |
-| **OAuth connectors (Google, Slack, M365)** | Per-connector OAuth flow is a permanent footprint we can't ship without an org user agreeing to scope it. | `road-to-internal-connectors.md` |
-
-### 2026-05 feedback citation — same three asks, same Hard-Floor
-
-The 9.3/10 feedback round (delivered in chat 2026-05-25) re-affirmed
-the same three P0 items the cancellations cover: OAuth knowledge
-connectors, IAM / org mode with admin roles + quotas + audit
-retention, and organization-shared memory. The verbatim asks land on
-the same Hard-Floor wall — no funded audit, no recruited team
-customer, no scope to adopt auth-adjacent code into the package.
-
-| 9.3/10 ask | Verbatim phrasing (2026-05-25) | Maps to cancellation |
-|---|---|---|
-| OAuth knowledge connectors | "GitHub / Jira / Confluence connectors so the team's docs join the agent's knowledge index" | `road-to-internal-connectors.md` |
-| IAM / org governance | "user accounts + admin roles + quotas + audit retention" | `road-to-team-sso.md` + `road-to-central-policy.md` |
-| Organization-shared memory | "team-wide memory so what one engineer answers, the next one inherits" | `road-to-team-context.md` |
-
-Each row carries the same three release gates: **recruited customer
-+ funded audit + maintainer ADR**. Until all three are met, the
-cancellation stands. Feedback rounds 11+ that re-ask the same
-questions land on this row directly.
-
-Each successor roadmap is an empty-named stub today; activation
-requires a recruited team customer plus a human-reviewed security
-audit. Until then, the answer to "team SSO when?" is: **not on this
-package, not on this roadmap**.
-
-## Decision posture going forward
-
-- **Default answer to org-mode requests**: point at this document.
-  Do not re-open the cancellation without a recruited customer +
-  funded audit.
-- **Default answer to small-team requests**: point at
-  [`small-team-recipe`](small-team-recipe.md). The recipe is
-  sufficient for 3–10 people, no code change required.
-- **Default answer to single-user requests**: workspace + Phases
-  4–7 deliver the daily experience.
-
-The Hard-Floor item stays in force. Nothing in Phase 9 lifts it.
-The successor roadmap stubs exist so cross-references resolve and
-so a future maintainer (or external contributor with funding) can
-pick them up without re-deriving the cancellation rationale.
-
-## Cross-references
-
-- Recipe: [`small-team-recipe`](small-team-recipe.md).
-- Archived: `agents/roadmaps/archive/road-to-internal-ai-os-deployment.md`.
-- Stubs (created by Phase 9 Step 4):
-  - `agents/roadmaps/stubs/road-to-team-sso.md`
-  - `agents/roadmaps/stubs/road-to-central-policy.md`
-  - `agents/roadmaps/stubs/road-to-team-context.md`
-  - `agents/roadmaps/stubs/road-to-internal-connectors.md`
-- Engineering safety floor: [`.augment/rules/non-destructive-by-default.md`](../../.augment/rules/non-destructive-by-default.md).

package/docs/design/adversarial-council-eval.md

@@ -1,106 +0,0 @@
-# Adversarial verification council eval — two-stage residual-detection design
-
-> Design artifact for `road-to-adversarial-verification-council` Phase 4. It
-> pins the benchmark that resolves the pre-registered `adversarial-council-
-> finding-coverage` claim (docs/CLAIMS.md, ADR-122). Writing this design is
-> autonomous; **curating the corpus and running the paid cross-vendor arm is a
-> maintainer cost decision**, gated on the corpus-validity check below.
-
-## What the claim is — and is not
-
-- **Is:** does a cross-vendor skeptic panel find materially more of the defects
-  that **survive a single strong judge** (the residual pool), at a false-positive
-  rate no worse than that judge on a controversial-but-correct control?
-- **Is not:** whether the council beats a solo model on *decision quality* — that
-  is the separate, `unbacked`, spend-gated `council-vs-solo-baseline`
-  (docs/design/council-vs-solo-baseline.md), explicitly out of scope.
-
-## The council's load-bearing critique (folded in)
-
-The AI-council debate (2026-07-14, anthropic/claude-sonnet-4-5 + openai/gpt-4o)
-converged on one real risk: the existing `cross-model-parity` corpus was built
-to show that different vendors catch different **obvious** things (parity), not
-to simulate the **residual** state after a competent first pass. Running the
-registered claim on it would force an honest-null as a *measurement artifact*,
-not a mechanism result. This design answers that with a two-stage protocol, a
-corpus-subtlety bar, a dual threshold, and a controversial-clean FP control.
-
-## Two-stage protocol
-
-1. **Stage 1 — single strong judge.** A single cross-model judge runs on every
-   planted-defect change. The defects it CATCHES are removed from scope.
-2. **Stage 2 — the panel on the residual.** Only the changes that PASS stage 1
-   (defect not caught) proceed to the Mode 9 panel. Recall is measured on this
-   **judge-passed residual pool** — the production-relevant quantity.
-
-This makes "residual detection" explicit rather than implicit in corpus
-selection.
-
-## Corpus-validity gate (blocks the registered run)
-
-The corpus must contain **judge-survivable subtleties**, published as a
-distribution before the registered run:
-
-- multi-file interaction defects,
-- subtle logic inversions that read as plausible,
-- security masked by correct-looking patterns,
-- edge cases in complex state.
-
-Publish the severity/subtlety distribution (share single-file <5 LoC vs
-multi-file interaction). A corpus skewed to trivially-detectable defects fails
-this gate — the registered run does not proceed until it passes.
-
-### Assessment of the existing corpus (2026-07-14)
-
-`internal/bench/orchestration/corpus/` (5 tasks: orch-01..03, pv-01 hollow,
-pv-02 control) was purpose-built for the parity signal and for A3
-production-validator Gate-A. `pv-01` is a deliberately **obvious** hollow impl
-(a floor sanity check), and none of the five tasks is designed as a
-judge-survivable residual defect. **Conclusion: this corpus does NOT meet the
-subtlety bar** — so the registered run is **blocked** pending a curated
-residual-defect corpus. The claim stays `unbacked` until then (no false
-`backed`).
-
-## Controversial-but-correct FP control
-
-The clean control includes correct-but-non-obvious cases (real perf/security
-design tradeoffs, uncommon patterns) — not only obviously-clean code — so the
-red-team posture's true FP cost is measured. Panel FP is compared to the
-single-judge FP on the SAME control.
-
-## Panel = cross-vendor
-
-The registered run and the opt-in high-risk tier use >=2 distinct **providers**
-(e.g. anthropic + openai), via the council transport (`council_cli.ts`,
-artefact/diff-as-text, read-only). The backed `cross-vendor-parity` signal is
-provider-level; same-vendor model diversity is insufficient for the claim.
-
-## The gate (locked at pre-registration)
-
-Encoded in [`src/scripts/_lib/adversarial_council_gate.ts`](../../src/scripts/_lib/adversarial_council_gate.ts)
-(`evaluateCouncilBench`), covered by `adversarial_council_gate.test.ts`:
-
-- (a) relative residual-recall lift >= **+25%**, AND
-- (b) absolute residual-recall lift >= **+8 pp**, AND
-- panel FP not worse than single-judge FP within the noise margin.
-
-Both recall thresholds are required — the dual gate guards the base-rate
-compression the council flagged (a high single-judge baseline makes relative
-lift easy but absolute must still clear). Threshold values are **locked**;
-corpus/protocol may be refined *before* the registered run, never the threshold
-after seeing results.
-
-## Outcome handling
-
-- **Pass** → flip `docs/CLAIMS.md#adversarial-council-finding-coverage` to
-  `backed` with the report pointer; document the recommended cross-vendor config.
-- **Honest-null** → record it (ADR-122 addendum + `docs/benchmark.md`), keep the
-  surface `off` by default permanently, mark the roadmap null-but-shipped-inert
-  (like recursive-verification).
-
-## Status
-
-- Gate logic: **built + tested** (deterministic TS).
-- Corpus-validity gate: **assessed — existing corpus fails the subtlety bar.**
-- Registered paid cross-vendor run: **deferred**, blocked on curating a
-  judge-survivable-subtlety corpus. Claim remains `unbacked`.

package/docs/design/council-vs-solo-baseline.md

@@ -1,92 +0,0 @@
-# Council-vs-solo baseline eval — design (pre-registered)
-
-> Design artifact for `road-to-feedback-8.11` Phase 3. It fixes the
-> methodology **before** the first billable call; the run itself is
-> spend-gated (blocker `council-baseline-spend-authorization` — the user
-> confirms the rendered estimate in-session). This document is the "design
-> the baseline" step — not the run. Companion claim:
-> `docs/CLAIMS.md § council-vs-solo-baseline` (status: unbacked until the run
-> resolves).
-
-## Why this exists
-
-The council deliberation protocol (stance tally, chairman, debate gates,
-anti-conformity) is well-built and default-off — but there is **no evidence
-that convening the council beats a single strong model** on any decision
-class. The 2026-07-12 feedback-disposition debate (claude-sonnet-4-5 +
-gpt-4o) REJECTED adding a ≥2-of-5 admission gate for exactly this reason and
-ADOPTED this baseline as the precondition for ANY further
-deliberation-protocol expansion: admission criteria must be derived from
-empirical decision characteristics, not a-priori heuristics.
-
-Shadow-log status at design time (2026-07-12): `agents/runtime/council/
-shadow-log.jsonl` is **absent/empty** on both the main checkout and the run
-worktree — the shadow-dispatch agreement mechanism has produced zero
-analyzable lines. That absence is itself the first finding: the only
-council-vs-solo signal the package planned to collect has no data, so a
-deliberate baseline run is the only path to a verdict.
-
-## Arms
-
-| Arm | What runs | Cost profile |
-|---|---|---|
-| A — solo | ONE strong model (the council's strongest configured member, single call, standard prompt) | 1 call/decision |
-| B — council | The full configured council in `debate` mode (2 members × ≤2 rounds, current defaults; stance tally ON so dissent is recorded) | 4–5 calls/decision |
-
-Same decision text, same context budget, both arms blind to each other.
-
-## Corpus — ≥30 real decisions
-
-- Source: real decision questions from the repo's own history — the
-  council-labelled golden set (labels final per the 2026-07-11 amendment; no
-  re-labelling) plus archived council question files whose ground-truth
-  disposition is now KNOWN (the decision shipped and survived, was reverted,
-  or was killed by later evidence). Minimum n = 30; pre-register the exact
-  list in the run manifest BEFORE the first call.
-- Class mix: at least 8 decisions per impact class {low, medium, high} so the
-  per-class analysis (the whole point — which characteristics correlate with
-  council lift) is not vacuous.
-
-## Metrics — fixed before data
-
-1. **Quality**: blind post-hoc grading of both arms' verdicts against the
-   known ground-truth disposition — primary judge = strongest available
-   model, blind second judge, report Cohen's κ (reuse `cohensKappa()` /
-   `judgeKappa()` from `src/scripts/check_quality_regression.ts`); verdict
-   admissible only at κ ≥ 0.60.
-2. **Cost**: tokens + USD (from the council cost ledger) + wall-clock per
-   decision, per arm.
-3. **Characteristics capture**: per decision, record the five feedback-
-   proposed dimensions (reversibility cost, material spend/risk,
-   multi-perspective conflict, evidence tension, policy/governance change) as
-   booleans AT PRE-REGISTRATION TIME (not after results) — so the ≥2-of-5
-   hypothesis is testable as a POST-HOc correlate without having gated
-   anything.
-
-## Kill criterion (falsifiable, from the 2026-07-12 debate)
-
-- **No lift anywhere**: if council decisions show no identifiable quality
-  lift on ANY decision subset (overall AND per impact class AND per
-  dimension-count stratum), further deliberation-protocol phases STOP and
-  the protocol goes maintenance-only; `road-to-opt-council-deliberation`
-  records the honest null.
-- **Lift on a subset**: derive empirical admission criteria FROM that
-  subset's recorded characteristics (which may or may not match the ≥2-of-5
-  heuristic — the data decides), and only then design an admission gate.
-- **Judge floor**: κ < 0.60 → record κ, withhold the win-rate, do not claim
-  either direction.
-
-## Spend gate
-
-Execution requires in-session user confirmation of the rendered estimate
-(existing council estimate machinery; ~30 decisions × (1 + ~4.5) calls —
-estimate rendered by `council estimate` at run time). Authoring the corpus
-manifest and this design is unblocked and free.
-
-## Non-goals
-
-- Not a cross-provider capability comparison (both arms use the configured
-  members; provider identity is held constant per arm definition).
-- Not a re-test of the deliberation features individually (stance tally,
-  chairman) — arm B runs the current default debate shape; feature ablations
-  are follow-ups only if B beats A at all.

package/docs/design/cross-model-parity-eval.md

@@ -1,82 +0,0 @@
-# Cross-model parity eval — re-scoped design
-
-> Design artifact for `road-to-opt-measurement-unblock` Phase 3 step 1. It
-> re-scopes the archive's most-deferred item (deferred across 4+ roadmaps) to the
-> **smallest capability** that produces a real cross-vendor parity signal, so the
-> build-vs-defer decision (step 2) rests on a concrete design, not the generic
-> "the harness doesn't exist". Writing this design is autonomous; **building and
-> running it is a maintainer cost decision** (step 2/3), disclosed and gated.
-
-## What changed since the last deferral
-
-| Original blocker | Status now |
-|---|---|
-| No delegable-task corpus | **RESOLVED** — `internal/bench/orchestration/corpus/` exists (`orch-*` orchestration tasks + `pv-*` production-validator tasks) |
-| Harness cannot execute model-emitted subagent calls | **STILL TRUE** — do not assume it away; re-scope around it |
-
-The corpus blocker no longer holds, so the item is re-openable — but only if we
-stop trying to build the thing that is still blocked (a full in-host harness that
-runs arbitrary model-emitted subagent calls).
-
-## The re-scope: council-transport execution, not an in-host harness
-
-**Don't** build a harness that executes model-emitted subagent calls end-to-end
-(the still-open blocker). **Do** reuse the capability that already exists: the AI
-council transport dispatches the *same* prompt to *multiple vendors* through
-`consult(members: ExternalAIClient[], …)` in
-[`src/scripts/ai_council/orchestrator.ts`](../../src/scripts/ai_council/orchestrator.ts).
-
-The smallest capability that yields a cross-model parity signal:
-
-1. **Task adapter.** Render each corpus task (`internal/bench/orchestration/corpus/*.md`)
-   into a single self-contained council prompt: the task + its rubric, asking the
-   model to *produce the findings it would surface* (not to actually spawn
-   subagents). This sidesteps the subagent-execution blocker — we measure the
-   model's **finding output on the delegable task**, not its ability to drive a
-   live subagent runtime.
-2. **≥ 2 vendors, same corpus.** Dispatch the identical prompt set to two distinct
-   vendors via the existing `ExternalAIClient` array — no new transport, no new
-   auth surface beyond what the council already has.
-3. **Per-host finding-count distribution.** For each (host × task), record the
-   count and the findings; aggregate to a per-host distribution over the corpus.
-4. **Blind judged quality (optional, gated).** If a quality signal beyond raw
-   counts is wanted, reuse the blind second-judge + Cohen's κ from
-   [`check_quality_regression.ts`](../../src/scripts/check_quality_regression.ts)
-   — the same discipline the Phase-1 rerun uses. This is the billable half; the
-   count distributions (step 3) are cheap and already informative.
-
-**Explicitly out of scope:** running the models' emitted subagent calls, a
-persistent multi-host runtime, any new vendor integration. If the signal needs
-more than council-transport can give, that is a *separate, later* build — named,
-not assumed.
-
-## What the signal feeds — `finding_floor` calibration
-
-`finding_floor` is an **inert mechanism today** (referenced in
-`run_skill_evals.ts` / `skill_linter.ts` / `evals.schema.json`); its recorded
-deferral reason was exactly the missing calibration input this eval produces. The
-per-host finding-count distributions calibrate the floor:
-
-- Derive the floor from the **cross-host lower envelope** (e.g. a low percentile of
-  the per-task finding counts across vendors) so the gate fires on a host/task that
-  under-produces relative to the cross-vendor norm, not relative to one vendor.
-- Once calibrated, promote `finding_floor` from inert to an **enforcing CI gate**
-  (its intended end state).
-
-## Build-vs-defer decision inputs (for step 2, maintainer)
-
-- **Cost:** the count-distribution pass (steps 1–3) is `N_tasks × N_vendors`
-  council calls — small and cheap; render the `council:estimate`-class disclosure
-  before the first call. The judged-quality half (step 4) roughly doubles it.
-- **Value:** unblocks `finding_floor` (arms a real CI gate) **and** produces the
-  first honest cross-vendor parity number the portfolio has ever had.
-- **Defer condition:** if built later, park with the concrete missing capability
-  named — here it would be "council-transport task-adapter for the orchestration
-  corpus", never the generic "harness doesn't exist".
-
-## Exit criteria mapping
-
-- This design doc **exists** (step 1 — done by writing this). ✓
-- Explicit **build/defer decision recorded** (step 2 — maintainer, cost attached). ⏳
-- If built: `finding_floor` calibration data exists and the gate is armed
-  (step 3 — gated on the decision + spend). ⏳

package/docs/design/length-neutral-judge-rerun.md

@@ -1,92 +0,0 @@
-# Length-neutral judge rerun — design
-
-> Design artifact for `road-to-opt-measurement-unblock` Phase 1. It fixes the
-> methodology **before** the first billable call; the run itself is a maintainer
-> `/dev/tty`-gated, money-moving execution (disclose the estimate, confirm the
-> budget in-session, then run). This document is the "design the rerun" step —
-> not the run.
-
-## Why a rerun
-
-The 2026-07-09 discipline-lift judge run was **inconclusive** and now gates ~40%
-of the active token-program portfolio. Three recorded failure modes made it
-un-trustworthy; each has a concrete fix below. Nothing ships from the prior run —
-its verdict is void, not "weakly positive".
-
-| # | Failure mode (2026-07-09) | Magnitude | Fix in this design |
-|---|---|---|---|
-| a | **Length confound** — the preferred arm was systematically longer, so the judge rewarded length, not discipline | 69% of variance | Length-matched pairs **and** a length-partialed rubric (both, belt-and-braces) |
-| b | **Judge inconsistency** — a single judge disagreed with itself / a second grader | 33% inconsistency | Stronger judge tier + a blind second judge, reported as Cohen's κ |
-| c | **Underpowered comparison** | p = 0.196 (n too small) | Pre-registered sample size from the golden corpus, fixed before the first call |
-
-## (a) Length confound — neutralise it two ways
-
-1. **Length-matched pairing.** For each decision task, constrain the two arms
-   (vanilla vs `essential` discipline) to within a **±15% token band** of each
-   other before judging. Pairs that cannot be matched within the band are
-   dropped from the primary analysis and reported separately (never silently
-   discarded). This removes length as a *between-arm* signal.
-2. **Length-partialed rubric.** The judge prompt scores **task quality only** and
-   is explicitly instructed that response length is **not** a quality signal;
-   the harness additionally records each response's token count and runs the
-   verdict through a length-partialed check — if the win-rate correlates with the
-   length delta (Spearman ρ over the surviving pairs), the run is flagged
-   `length-confounded` and the verdict is withheld, exactly as the exit criterion
-   demands ("no length confound flag").
-
-Both, not either: matching removes the gross effect, partialing catches residual
-leakage the band still admits.
-
-## (b) Judge inconsistency — stronger tier + a second judge, reported as κ
-
-- **Judge tier.** Use the strongest available judge model for the primary grade
-  (not the cheapest); the grading cost is a fraction of the generation cost and
-  judge quality is the binding constraint here.
-- **Blind second judge + Cohen's κ — reuse, do not rebuild.** The second-judge
-  agreement machinery already exists: `cohensKappa()` + `judgeKappa()` in
-  [`src/scripts/check_quality_regression.ts`](../../src/scripts/check_quality_regression.ts)
-  align two judges' per-pair winner labels by task id and return chance-corrected
-  κ. Run both judges **blind to arm labels** and to each other; report κ
-  **alongside every verdict**.
-- **κ floor.** The verdict is admissible only when **κ ≥ 0.60** (substantial
-  agreement). Below the floor, the win-rate rests on an unreliable grader — record
-  the κ, do **not** report the win-rate as a finding, and stop (see disposition).
-
-## (c) Underpowered — pre-register the sample size
-
-- **Corpus.** Draw decision tasks from the council-labelled golden set landed by
-  PR #885 (labels are final per the 2026-07-11 amendment — **no re-labelling**).
-- **Power target.** Pre-register n for **80% power** at the smallest
-  effect worth shipping (target: detect a **≥ 10pp** win-rate difference from 50%
-  at α = 0.05). Fix n **before** the first billable call; do not grow n after
-  seeing results (that is the p-hacking the prior run's `p = 0.196` invites).
-- **Statistic.** Paired win/loss over matched pairs → the exact binomial
-  sign-test (`signTestP` already in `second_brain_retrieval.ts`) or McNemar
-  (`bench_ab_v2_stats.ts`); report the two-sided p and the effect size, never a
-  bare "significant".
-
-## Report schema (verdict artifact)
-
-Written under `internal/bench/reports/` with, inline and non-optional:
-
-- per-arm win/loss/tie counts over the **surviving matched pairs** (+ the dropped-pair count);
-- **κ** (both judges) and the κ floor used;
-- the length-confound diagnostic (Spearman ρ of win-rate vs length delta) and the
-  pass/`length-confounded` flag;
-- pre-registered n, achieved power, and the sign-test / McNemar p + effect size;
-- a one-line **verdict**: `ships-lift` / `honest-null` / `inconclusive-<reason>`.
-
-## Disposition (Phase 1 step 4)
-
-- **Trustworthy verdict, either direction** (κ ≥ floor, no length flag, powered):
-  update the token-program tracking table in `road-to-token-proof-and-story.md`
-  and unblock/close the dependent gates.
-- **Second inconclusive:** record *why* with the diagnostics above and **stop** —
-  no third run without a further design change. The anti-pattern this roadmap
-  kills is "gate pending" with no diagnosis.
-
-## What this design does NOT decide
-
-The **execution** — the cost estimate, the in-session budget confirmation, and the
-paid paired run — is the maintainer's, disclosed and confirmed per the acceptance
-criteria. This document only makes the run, when authorized, trustworthy.

package/docs/design/utilization-window-criteria.md

@@ -1,51 +0,0 @@
-# Utilization-window decision criteria — pre-registered
-
-> Design artifact for `road-to-feedback-8.11-2` Phase 0. The engagement
-> observation window (telemetry.artifact_engagement, id-only,
-> PII-excluded-by-construction) has been RUNNING in the agent-config repo
-> since 2026-07-12. Per the repo's claims convention, the window's decision
-> rules are fixed HERE, BEFORE the numbers accumulate — the reviewer's
-> warning was precise: without pre-fixed criteria "the window ends with
-> many events and no decidable statement." Companion claim:
-> `docs/CLAIMS.md § utilization-window-decidability`.
-
-## Observation floor (all three, else "underpowered")
-
-1. **≥ 100 recorded task boundaries** in `.agent-engagement.jsonl`
-   (boundary_kind `task` or `phase-step`).
-2. **≥ 2 distinct hosts** contributed records (host identity read from the
-   session context at analysis time, not stored in the event — the event
-   schema stays id-only; if host cannot be attributed without widening the
-   schema, the floor degrades to "≥ 2 distinct recording periods ≥ 14 days
-   apart" and this deviation is recorded in the closing report).
-3. **≥ 45 elapsed days** since 2026-07-12.
-
-Below the floor at day 90 → the window is **underpowered**: extend ONCE by
-30 days. Still below → STOP, record the honest null ("insufficient natural
-usage volume to decide utilization"), and do NOT rebuild collection
-apparatus without a new demand signal.
-
-## Decision rules (fixed now — no goalpost-moving)
-
-| # | Observation at window close | Bound decision |
-|---|---|---|
-| D1 | Artifact kind entry (skill/rule/command/guideline/persona id) **loaded-never-consulted** across the full window (requires the U1a `loaded` denominator; if U1a has not landed, D1 degrades to consulted-set analysis and says so) | Goes on the **retirement-candidate list** feeding U1's ranked cut list — candidate, not auto-cut; kernel + safety floors exempt by construction |
-| D2 | Artifact **consulted-never-applied** with ≥ 5 consultations and applied-ratio < 10% | Goes on the **trigger-review queue** (description/trigger overhaul, not deletion) |
-| D3 | Window closes **above the floor** | The first U1 report MUST name ≥ 1 concrete keep/cut/review decision per artifact kind, or record per kind why the data does not support one |
-| D4 | Window closes **below the floor** (after the one extension) | Honest null; lifecycle-automation and field-outcome-ledger gates STAY closed (their revisit-if remains "≥ 1 full window") |
-
-## Explicitly out of scope for this window
-
-- **Outcome-quality attribution** (did artifact X improve the result) —
-  needs the `loaded` denominator plus far more volume; stays with U1a.
-- **Cost-vs-rework economics** — owned by the orchestration telemetry
-  track (`road-to-subagent-value-realization-followup`).
-- **Cross-repo aggregation** — the window is this repo only (council
-  condition from the 8.11 disposition).
-
-## Kill criterion
-
-If the window closes decidable (D3) but its decisions are cited by zero
-actual portfolio changes within 2 releases, the analysis layer (not the
-telemetry) is the dead weight — record that honest null before building
-any further reporting on top.