diff --git a/docs/handoff/GPT55-MOBILE-DISPATCH.md b/docs/handoff/GPT55-MOBILE-DISPATCH.md new file mode 100644 index 00000000..4676db9f --- /dev/null +++ b/docs/handoff/GPT55-MOBILE-DISPATCH.md @@ -0,0 +1,372 @@ +# GPT-5.5 Mobile/GitHub-Connector Dispatch — In-Flight Work + +**Audience:** GPT-5.5 accessed via mobile + GitHub connector while Shay travels +**Mode:** Read-only execution surface (no test runs, no eval runs, no Python +interpreter). Output is markdown files committed via the connector and PRs +opened against `AssetOverflow/core`. +**Risk profile:** Zero — every task is docs-only, no code paths touched, no +pack mutations, no runtime change. `wrong=0` cannot be violated. +**Cadence:** Pick one task. Complete it fully (including the PR open). Move +to the next. Don't parallelize — mobile + connector tooling is single-thread. + +--- + +## Shared constraints + +- Open one PR per task. Each is a separate branch off `origin/main`. +- Branch naming: `docs/gpt55-task-N-` where `N` is the task number. +- File staging: explicit. **Never** `git add -A`. **Never** commit + `engine_state/`. +- Markdown-only output (CLAUDE.md §Documentation Discipline — no standalone + HTML, no dashboards). Mermaid + `
` collapsibles permitted. +- Honour CLAUDE.md's existing doctrine sections; specifically: + - §"Schema-Defined Proof Obligations" — any new schema you propose must + name an executing test that can meaningfully fail + - §"Non-Negotiable Field Invariant" — never propose anything that + weakens `wrong=0` or the field invariant + - §"Validation Through CLI" — refer to CLI lanes rather than ad-hoc + pytest invocations +- Cite filenames + line numbers (`path/file.py:LINE`) for every code + reference. Verify each reference resolves before committing. +- If a task's deliverable requires a code change (not docs), **stop and + flag it in the PR body** — do not attempt code edits via the connector. + +--- + +## Task 1 — Draft ADR-0168 (FrameClaim scoping) + +**Branch:** `docs/gpt55-task-1-adr-0168-frameclaim` +**Output:** `docs/decisions/ADR-0168-frameclaim-ratification.md` +**Priority:** Highest (this is the next gate after the LexicalClaim slice) + +### Context to read first + +- `docs/decisions/ADR-0167-audit-as-teaching-evidence.md` — the parent + scoping ADR with the five sub-types proposed +- `docs/handoff/ADR-0167-FOLLOWUPS.md` §1 — the queued sub-type work, + specifically the FrameClaim row +- `teaching/math_lexical_ratification.py` — the LexicalClaim handler + template (what your ADR's analogous handler would look like) +- `teaching/math_evidence.py` — `SUB_TYPE_FOR_OPERATOR` table; FrameClaim + maps from `pre_frame_filler_sentence` and `multi_subject_sentence` +- `evals/gsm8k_math/train_sample/v1/audit_brief_11.json` — the 9 + `pre_frame_filler_sentence` cases your ADR will eventually resolve +- `evals/gsm8k_math/train_sample/v1/audit_brief_11.md` §"design tension" + — the rejected one-line fixes and why they fail wrong=0; FrameClaim is + the structural answer +- `language_packs/data/en_core_math_v1/lexicon/` — pack mutation surface + for verb-category reclassification + +### Deliverable shape + +ADR-0168 must answer for FrameClaim what ADR-0167 answered for the +overall wire: + +1. **Scope.** FrameClaim ratifies a verb-category reclassification. + Specifically: when the operator reviews a `pre_frame_filler_sentence` + refusal, FrameClaim's handler reclassifies the unrecognised verb + from `drain_token` (or its current category) to a frame-opener + category (`accumulation_verb` / `depletion_verb` / `transfer_verb` / + `possession_verb` / `capacity_verb`). +2. **Why this is not LexicalClaim.** Reclassification is structurally + different from adding a new lemma: it changes the frame-opening + behaviour of an EXISTING entry. The hazard is real — reclassifying + `does` to `accumulation_verb` would re-introduce the case 0050 + hazard (W2-D pinned this in `SAFE_CATEGORIES`). +3. **Six open questions (analogous to ADR-0167's).** Answer each in + the ADR draft, not in code: + - (Q1) What sub-types of FrameClaim are needed? (E.g. distinct + handlers per target category, or one parameterised handler?) + - (Q2) What new SAFE_CATEGORIES allowlist applies? + - (Q3) How does the ratification prevent the case 0050 hazard? + Concrete answer required, not hand-waved. + - (Q4) What evidence signature normalisation does FrameClaim need? + (Token-only, or token+target-category?) + - (Q5) How does graph completeness gate this category change at the + downstream solver level? + - (Q6) What ablation test would prove this handler doesn't admit + a graph for a sentence whose verb the operator declined to + reclassify? +4. **Three-question test (ADR-0166).** Answer Q1/Q2/Q3 of ADR-0166 + for FrameClaim explicitly. If any of the three doesn't pass cleanly, + say so — the ADR can defer rather than pretend. +5. **Implementation outline.** A wave structure analogous to + ADR-0167's: which W1/W2/W3 deliverables, what operator-to-brief + matching, what's parallelisable. + +### PR body must include + +- Link to ADR-0167 and FOLLOWUPS §1 +- Quote the case 0050 hazard text from + `feedback-wrong-zero-hazard-case-0050` memory (Shay can paste it) +- Explicit "docs-only; no code change" callout +- The recommendation: ship or defer? Whichever, defend it. + +### Out of scope for this task + +- Implementing FrameClaim. ADR is scoping only. +- Touching `teaching/`, `language_packs/`, or any test file. +- New eval lanes (ADR-0166 still gates). + +--- + +## Task 2 — `discrete_count_statement` injector specification audit + +**Branch:** `docs/gpt55-task-2-dcs-injector-spec` +**Output:** `docs/handoff/discrete_count_statement-injector-spec.md` +**Priority:** Highest-leverage (21/47 GSM8K refusals are this one category) + +### Context to read first + +- `evals/gsm8k_math/train_sample/v1/report.json` — the post-eval + refusal records; filter for + `"category=discrete_count_statement"` (21 cases) +- `evals/gsm8k_math/train_sample/v1/cases.jsonl` — original problem + text for each of those 21 cases +- `generate/recognizer_match.py` — the `match` function that's + over-matching +- `generate/recognizer_anchor_inject.py` — the `inject_from_match` + function; the empty-tuple return path is the bug surface +- `engine_state/recognizers.jsonl` (read-only — **never commit this**) + — the ratified recognizer specs including the + `discrete_count_statement` canonical pattern +- `docs/decisions/ADR-0163-gsm8k-path-to-mastery.md` — the roadmap + that introduced this recognizer +- `docs/decisions/ADR-0163.D.2-discrete-count-statement.md` (if it + exists — locate and read it) + +### Deliverable shape + +A specification document, not an implementation. The document must: + +1. **Categorise the 21 cases.** Read each problem text; group by + sub-structure. Common shapes likely include: + - "X has N " pure initial-state + - "X has N and M " multi-quantity initial + - "There are N " subject-anonymous initial + - "N are " attribute-on-count + - Comparatives ("N more than M ") + The grouping is the load-bearing part — exact buckets aren't pre- + determined; let the data dictate. +2. **For each sub-shape**, propose: + - What `parsed_anchors` shape an injector would have to produce + - What `CandidateInitial` / `CandidateOperation` it maps to + - What admissibility check would catch wrong>0 admissions + - Which sub-shapes are LexicalClaim-resolvable (e.g. just a missing + noun) and which need FrameClaim / CompositionClaim +3. **Identify the over-matching root cause.** The recognizer's + canonical pattern matches any number+noun. Propose specific + tightening conditions (e.g. require a frame-opener verb, require + the noun to be in a count-noun whitelist). +4. **Quantify the lift potential.** Of the 21, how many would resolve + under each sub-shape's hypothetical injector? Be honest about + which ones still wouldn't resolve even with the injector (they + have downstream barriers — pronoun, fraction, etc.). +5. **Sequencing recommendation.** Which sub-shape's injector should + ship first? Lift-per-risk, not raw count. + +### PR body must include + +- Per-sub-shape lift estimate (table) +- A statement that NO injector implementation is being proposed — + this PR is specification only +- Cross-reference to ADR-0167-FOLLOWUPS §1 (FrameClaim) and + §"discrete_count_statement over-matching" + +### Out of scope for this task + +- Implementing any injector +- Modifying the recognizer canonical pattern +- Touching `language_packs/` or `teaching/` +- Running the eval (you can't anyway) + +--- + +## Task 3 — Recognizer registry audit + +**Branch:** `docs/gpt55-task-3-recognizer-audit` +**Output:** `docs/handoff/ratified-recognizer-registry-audit.md` +**Priority:** Medium (informs Task 2 and future injector work) + +### Context to read first + +- `engine_state/recognizers.jsonl` (read-only) — the 7 ratified + recognizers from #315 onward +- `generate/recognizer_match.py` — match logic +- `generate/recognizer_anchor_inject.py` — injection logic, including + which categories have injectors and which return `()` +- The eval report from Task 2 — refusal-class counts per recognizer + category + +### Deliverable shape + +A table-driven survey: + +| Recognizer category | Match logic precision | Injector present? | GSM8K refusal count | Lift potential | Risk class | +|---|---|---|---:|---|---| +| `discrete_count_statement` | over-broad | no | 21 | high | high (case 0050 class) | +| `currency_amount` | ? | ? | 4 | ? | ? | +| `rate_with_currency` | ? | ? | 3 | ? | ? | +| ... | ... | ... | ... | ... | ... | + +For each row, write a one-paragraph commentary explaining: +- What the recognizer is supposed to catch +- What it actually catches (the over-broadness or precision) +- Whether the injector is feasible (lexical-only? structural? multi-pack?) +- The case 0050 hazard analogue for THIS category + +### PR body must include + +- A "promote injector / tighten match / retire recognizer" recommendation + for each row +- An "if you fix one, fix this one first" prioritisation + +### Out of scope for this task + +- Implementing any recognizer change +- Retiring any recognizer (proposal-only) +- Touching `engine_state/` directly — read-only + +--- + +## Task 4 — FOLLOWUPS §6 ablation test specification + +**Branch:** `docs/gpt55-task-4-holonomy-ablation-spec` +**Output:** `docs/handoff/holonomy-ablation-test-spec.md` +**Priority:** Low-urgency, high-information + +### Context to read first + +- `docs/handoff/ADR-0167-FOLLOWUPS.md` §6 (when merged from PR #360) +- `language_packs/compiler.py:558` — `_apply_mounted_primary_domain_resonance` + (the architectural-invariant comment names the gap) +- `tests/test_alignment_graph.py:73` — + `test_holonomy_alignment_case_positive_closer_than_negative` (the + existing proof) +- `language_packs/schema.py:181` — `HolonomyAlignmentCase` schema + +### Deliverable shape + +A specification (not an implementation) for an ablation test that +isolates *structurally-derived* convergence from *blend-induced* +convergence. The spec must: + +1. **Name the ablation surface.** What part of + `_apply_mounted_primary_domain_resonance` needs to be temporarily + disabled or parameterised for the test? +2. **Name the test contract.** With ablation active (blend factor = 0), + does the positive-closer-than-negative assertion still hold? If + yes, structural derivation is real; if no, the test is gated by the + blend. +3. **Name the predicted outcome.** Best guess: blend-gated. Document + why (the 40% nudge is sizeable; without it, the morphology rotors + alone may not produce enough convergence). +4. **Name the honest reframing path.** If the ablation fails, the + `HolonomyAlignmentCase` contract should be reframed from "proves + structural divergence with coherent convergence" to "proves + endpoint similarity under the mount-time blend." Suggest the exact + docstring/schema text. + +### PR body must include + +- Cross-reference to FOLLOWUPS §6 and CLAUDE.md §"Schema-Defined Proof + Obligations" +- Explicit "spec only; no test implementation in this PR" callout + +### Out of scope + +- Implementing the ablation test +- Modifying the holonomy test or schema +- Modifying `_apply_mounted_primary_domain_resonance` + +--- + +## Task 5 — Cognition contemplation partition fix specification + +**Branch:** `docs/gpt55-task-5-contemplation-partition-spec` +**Output:** `docs/handoff/contemplation-pack-indexing-partition-spec.md` +**Priority:** Medium (this is FOLLOWUPS §5a) + +### Context to read first + +- `docs/handoff/ADR-0167-FOLLOWUPS.md` §5a +- `docs/handoff/ADR-0167-W2C-cross-domain-audit.md` — Gemini's W2-C + audit; the specific partition risks +- `teaching/contemplation.py::contemplate()` — the function that uses + hardcoded cognition pack/corpus indexes +- `teaching/discovery.py` — `DiscoveryCandidate` with the `domain` + field added by W2-C +- `language_packs/data/en_core_math_v1/` — what a math pack looks like + (for the alternate-domain branch) + +### Deliverable shape + +A surgical patch specification (not an implementation): + +1. **Inventory.** Which exact lines in `teaching/contemplation.py` + assume cognition? +2. **Patch surface.** Minimum change to make those lines respect + `candidate.domain`. +3. **Test surface.** What test(s) would catch a regression where a + math candidate silently fetches cognition pack data? +4. **Backwards compatibility.** Confirm the default (`domain="cognition"`) + preserves current behaviour byte-identically. + +### PR body must include + +- Cross-reference to W2-C audit and FOLLOWUPS §5a +- "Spec only; implementation in a follow-up PR" callout + +### Out of scope + +- Implementing the patch +- Touching `teaching/contemplation.py` +- Running cognition regression tests (you can't anyway) + +--- + +## Operational notes + +- **Pace yourself.** Mobile + connector tooling has latency. One task per + session is honourable; trying to finish all five in one go invites errors. +- **Cite line numbers.** Every code reference must include `path:LINE` and + be verified to resolve. If you can't verify via the connector, drop the + specific line number and reference the function name instead. +- **No code edits.** If a task starts feeling like it needs a code change, + flag it in the PR body and stop. Do not attempt code edits via the + connector — the test discipline can't be honoured from mobile. +- **Honest progress reports.** Each PR's body should report what you + actually concluded — including any sub-shapes you couldn't categorise, + any line numbers you couldn't verify, any open questions that need + Shay's input. +- **If you finish all five.** Open a meta-PR adding a section to + `docs/handoff/ADR-0167-FOLLOWUPS.md` linking to all five spec docs. + +## What NOT to attempt from the connector + +- Implementing FrameClaim, CompositionClaim, or any other handler +- Implementing any injector for `discrete_count_statement` or any other + recognizer category +- Implementing the holonomy ablation test +- Implementing the contemplation partition fix +- Running `core test --suite *` or `core eval cognition` (mobile cannot) +- Mutating any pack file under `language_packs/data/` +- Committing anything under `engine_state/` +- Force-pushing or rewriting history on any branch + +If in doubt, the rule is: **specs and audits, not implementation.** + +--- + +## Cross-references (for context) + +- `CLAUDE.md` — project doctrine +- `docs/decisions/ADR-0166-measurement-capability-sequencing.md` — the + three-question test every spec must answer +- `docs/decisions/ADR-0167-audit-as-teaching-evidence.md` — the parent + wire all five sub-types extend +- `docs/handoff/ADR-0167-FOLLOWUPS.md` — the canonical follow-up queue; + Tasks 1, 2, 4, 5 all extend items already named there +- `docs/decisions/SESSION-2026-05-27-adr-0167-parallel-dispatch.md` — + the wave narrative; reading this gives the full context for why each + task is shaped the way it is