From bbe71899499145c5ab6ca99e1100176899cbb524 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 07:41:12 -0700
Subject: [PATCH 1/7] =?UTF-8?q?Guide:=20gate-semantics=20reform=20(F12)=20?=
 =?UTF-8?q?=E2=80=94=20recommended-baseline=20rename,=20label=20timing=20f?=
 =?UTF-8?q?rames,=20deviation=20marks,=20bare-(default)=20ban?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- The §6.0 express lane is named 'recommended baseline build' with a required
  one-line explanation (course choices where light, substitutions where heavy);
  never presented as the course's own configuration.
- Two-label timing frames: Default column = generator's zero-setup call at
  generation time; '(Recommended)' = build agent's contextual call at gate time.
- Resolved-decision checklist carries per-row deviation marks; baseline path
  walks through departing rows.
- Bare '(default)' banned as an option label everywhere (gate + Options cells);
  the two sanctioned labels and their merged form are the only option labels.
- §14 audit lines updated by reference.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .../references/spec-generation-guide.md       | 45 ++++++++++++-------
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/.claude/skills/generate-spec/references/spec-generation-guide.md b/.claude/skills/generate-spec/references/spec-generation-guide.md
index cb43ba4..436bb63 100644
--- a/.claude/skills/generate-spec/references/spec-generation-guide.md
+++ b/.claude/skills/generate-spec/references/spec-generation-guide.md
@@ -129,7 +129,7 @@ The **Decision Ledger** is the spec's second section (§6, right after the §0 p
 - **Category** — the §5.5 entry route that admitted the row (`design-argued | design-structural | realization | contradicted | learner`). Exactly one label, chosen by the precedence in the surfacing bar below; it determines the row's position in the fixed row order.
 - **Decision** — short name (e.g. "persistent store", "memory-core topology", "project").
 - **Invariant** — what MUST hold to preserve the taught pattern. For learner-context rows it carries only the pattern's capability requirements on that dimension (§3) — typically empty for project/data/goal/scope-boundary, never invented. Write it precisely: this field doubles as the contract a future integration must satisfy.
-- **Options** — realizations that satisfy the invariant, from course-faithful to tech-agnostic. The course's own technology always appears here even when it is not the default — and when it is not the default (a §3 branch-1 substitution), tag that entry **"(course default)"** in the cell text, so the §6.0 gate's labeling duty is deterministic: the build agent must never have to infer which option the course actually used.
+- **Options** — realizations that satisfy the invariant, from course-faithful to tech-agnostic. The course's own technology always appears here even when it is not the default — and when it is not the default (a §3 branch-1 substitution), tag that entry **"(course default)"** in the cell text, so the §6.0 gate's labeling duty is deterministic: the build agent must never have to infer which option the course actually used. Never tag an Options entry with a bare "(default)": the Default column carries default-ness, and §6.0's two labels (provenance and recommendation) are the only sanctioned option labels.
 - **Default (course-derived)** — **exactly one** buildable target (§3). For heavy-dependency rows, resolved by the §3 dependency precedence, with the branch stated. When the default is the course's *example realization* — a domain-specific instantiation (its demo data, its example tools) rather than the pattern itself — the Decision or Default cell must say so and mark it as expected to be swapped when the learner's project (the project row) differs: the invariant, not the example, is what must survive.
 - **Trade-off** — what switching costs (carries the course's *spoken* trade-offs: re-embedding, re-tuning, lateral-or-worse results).
 - **Owner** — a label only: `learner`, `course`, or `course+learner` (§9). Metadata; never gates behavior.
@@ -285,11 +285,11 @@ A Decision Ledger that no one is shown is worthless. A build agent's default beh
 
 - **Imperative and build-agent-addressed.** "You are the build agent. Before writing ANY code, you MUST…" — not a passive "review before build" header (which reads as a note to a human skimming and gets skipped).
 - **First.** It is spec section `## 0`, ahead of everything including the Decision Ledger, visually isolated.
-- **An express lane for the as-is builder, asked first.** The gate's FIRST question offers exactly two paths: build the course-default takeaway **as-is** (every Ledger row resolves to its Default), or **customize** the decisions row by row. Choosing as-is skips the per-row questions entirely — the agent prints the full resolved-decision checklist (every row = its Ledger default) and begins building; choosing customize enters the one-question-per-row loop. This is NOT an escape clause (§12.10): the user gave an explicit answer that covers every row — the same "defaults are fine" reply the determinism argument already sanctions — and the printed checklist still makes completeness visible. What stays forbidden is proceeding on *silence*.
+- **An express lane for the baseline builder, asked first — and named honestly.** The gate's FIRST question offers exactly two paths: the **recommended baseline build** (every Ledger row resolves to its Default), or **customize** the decisions row by row. The express path is named "recommended baseline build" — never "build as-is with the course's setup" or any phrasing presenting it as the course's own configuration — because on substitution rows (§3 branch 1) the Default deliberately departs from what the course ran, so a course-default framing misattributes those rows: the same provenance error the labeling rule below prevents at option level, recurring at path level. The baseline option's text must carry a one-line explanation stating both halves: most rows resolve to the course's own choices, and wherever the course's choice needs setup the learner may not have (a paid key, an admin-provisioned service), a lighter equivalent stands in — with the step-5 checklist marking exactly where. Choosing the baseline skips the per-row questions entirely — the agent prints the full resolved-decision checklist and begins building; choosing customize enters the one-question-per-row loop. This is NOT an escape clause (§12.10): the user gave an explicit answer that covers every row — the same "defaults are fine" reply the determinism argument already sanctions — and the printed checklist still makes completeness visible. What stays forbidden is proceeding on *silence*.
 - **Presents EVERY Ledger row.** Do not have the gate re-filter or tier rows — the §5.5 surfacing bar already decided what became a row, so every row is by construction worth showing. (Never key the gate on row numbers; row identities are course-specific.)
 - **One question per row — do not depend on a channel's item cap.** Interactive question tools cap how many questions fit in one call (Claude Code's `AskUserQuestion` allows at most a few), and a Ledger can have many rows. If the gate says "present every row" without saying *how*, the agent improvises — batching inconsistently, or (worse) presenting a first batch, getting a reply, and treating the build as unblocked while the rest are never asked (§12.11). Fix the mechanism deterministically: **one row = one question**, looped until every row is asked. One-per-row has no batch boundary to mis-track and its completeness is a plain count (N rows ⇒ N questions). **Never hardcode a numeric cap** ("4") into the gate — that is one environment's limit; state the capacity-relative rule instead so it holds for an uncapped or plain-text channel too.
-- **Checklist-echo gates the build, not "a reply happened".** Keying resumption on "the user replied" fails the moment many rows exist: a reply to *some* rows satisfies it, and the rest are buried. Require a **visible artifact** instead — before any code, the agent prints a checklist of every row with its resolved value. A completion-driven agent cannot produce that checklist without having resolved every row, and the user/reviewer can *see* completeness. A printed artifact beats an internal "did I ask N times?" count precisely because the same agent that skips rows is the one that would judge the count.
-- **Labels the course's actual choice "(course default)"; the build agent's own "(Recommended)" flag may coexist.** "(course default)" is factual provenance — what the course actually did — and must always mark the option the course actually used. On a **substitution row** (§3 dependency-precedence branch 1) that is the course-faithful **Options** entry, NOT the substituted Ledger Default: labeling the substitute "(course default)" misattributes it (observed in real learner feedback — a SQLite+Chroma default presented as the course's choice when the course ran Oracle). Separately, the build agent may mark an option "(Recommended)" per its own judgment or its question tool's convention (Claude Code's `AskUserQuestion` suggests exactly this) — that is advice about *this* learner's project, a different claim from provenance, and it is allowed. The two labels compose: when the agent's recommended option differs from the course's choice, both labels appear, each on its own option; when the recommended option IS the course's choice, use the single combined label **"(Recommended - course default)"**. A recommendation never removes or moves the "(course default)" label.
+- **Checklist-echo gates the build, not "a reply happened".** Keying resumption on "the user replied" fails the moment many rows exist: a reply to *some* rows satisfies it, and the rest are buried. Require a **visible artifact** instead — before any code, the agent prints a checklist of every row with its resolved value. A completion-driven agent cannot produce that checklist without having resolved every row, and the user/reviewer can *see* completeness. A printed artifact beats an internal "did I ask N times?" count precisely because the same agent that skips rows is the one that would judge the count. The checklist also carries **deviation marks**: each row's line states whether its resolved value is the course's actual choice or departs from it — a substitution row resolved to its Default departs by construction; a customize answer may too — naming the course's choice on every departing row. And on the baseline path, the agent walks the learner through the departing rows alongside the checklist (each row's course choice, and the reason its Default substitutes — the row's own branch note carries it), so the express lane never hides where the baseline differs from the course.
+- **Labels the course's actual choice "(course default)"; the build agent's own "(Recommended)" flag may coexist.** "(course default)" is factual provenance — what the course actually did — and must always mark the option the course actually used. On a **substitution row** (§3 dependency-precedence branch 1) that is the course-faithful **Options** entry, NOT the substituted Ledger Default: labeling the substitute "(course default)" misattributes it (observed in real learner feedback — a SQLite+Chroma default presented as the course's choice when the course ran Oracle). Separately, the build agent may mark an option "(Recommended)" per its own judgment or its question tool's convention (Claude Code's `AskUserQuestion` suggests exactly this) — that is advice about *this* learner's project, a different claim from provenance, and it is allowed. The two labels compose: when the agent's recommended option differs from the course's choice, both labels appear, each on its own option; when the recommended option IS the course's choice, use the single combined label **"(Recommended - course default)"**. A recommendation never removes or moves the "(course default)" label. The two labels also differ in **when their claims are made**: the Ledger's Default column is the *generator's* recommendation, fixed at generation time on zero-setup grounds (buildable as-is with nothing the learner must provision — the same grounds §3's precedence uses); "(Recommended)" is the *build agent's* judgment at gate time, made with the learner's context (their earlier gate answers; keys or services they actually hold). With no gate-time reason to depart, the agent recommends the row's Default; with one (say, the learner holds the key a keyed-tool row's course option needs), "(Recommended)" may land on any option — the label that never moves is "(course default)". These two labels, plus their merged form, are the **only sanctioned option labels** anywhere the spec presents choices — gate questions and Ledger Options cells alike. Never label an option with a bare "(default)" or "(Default)": default-ness is carried by the Ledger's Default column, not by a label, and a third label re-opens the provenance-vs-advice confusion the two-label design exists to close (observed as direct owner confusion in review).
 - **A hard stop, with no escape clause.** Presenting the decisions must end the agent's turn: it stops and waits for the user's reply before writing any code or touching any file. Do **not** give it a "proceed if there's no response" release valve — that is the loophole that re-opens §12.10: the agent *always* trivially has "no response" the instant it finishes presenting, so it reads the valve as immediate permission and the ask becomes theater. A narrower "proceed if launched non-interactively" escape is the same hole, smaller — drop it too; a completion-driven agent steers into whatever escape exists. Determinism is **not** at risk from waiting: it comes from every row having one course-derived default (§3, Known-Trap #7), so a user who replies "defaults are fine" lands on the identical target. Waiting changes *when* the agent proceeds, never *what* it builds. (If a genuinely headless harness cannot answer, the absent reply stalls that build — the harness's constraint to resolve by pre-answering, not a hole the spec should pre-drill.)
 - **Structured tool required when available; still portable.** If the environment has an interactive structured-question tool (Claude Code's `AskUserQuestion` or an equivalent), the gate MUST require using it — it is the reliability lever, not a mere suggestion. Name specific tools only as *examples* of the class, never as a hard dependency: a non-Claude agent (Codex, Cursor, plain chat) with no such tool must still comply by listing the rows in its reply and asking. So the rule is "use a structured question tool **if you have one**, else ask in plain text" — mechanism-*required* where possible, mechanism-*agnostic* in fallback.
 
@@ -308,18 +308,23 @@ not because they are the right choice for this person's project.
    in yours), you MUST use it for the questions below — do not paraphrase them into a prose
    paragraph. Only if no such tool exists, list the rows in your reply and ask the user to
    respond to each.
-2. **First question — build as-is, or customize?** Ask exactly one question with two options:
-   build the course-default takeaway **as-is** (every Ledger row resolves to its Default), or
-   **customize** the decisions row by row. If the user chooses as-is, skip step 3 — go straight
-   to the step-5 checklist and build. If the user chooses customize, continue with step 3.
+2. **First question — recommended baseline build, or customize?** Ask exactly one question with
+   two options: the **recommended baseline build** — every Ledger row resolves to its Default:
+   mostly the course's own choices, with a lighter stand-in wherever the course's choice needs
+   setup you may not have (a paid API key, an admin-provisioned service); the step-5 checklist
+   marks exactly where the baseline differs from the course — or **customize** the decisions row
+   by row. If the user chooses the baseline, skip step 3 — go straight to the step-5 checklist
+   and build. If the user chooses customize, continue with step 3.
 3. **Present the Ledger ONE ROW AT A TIME — one question per row.** For each row ask a single
    question: the **Decision** as the prompt, its **Options** as the choices. Append
    "(course default)" to the option the course actually used — on a substitution row that is
    the course-faithful Options entry, not the Ledger Default. You may also mark an option
-   "(Recommended)" per your own judgment or your question tool's convention; when your
-   recommended option IS the course's actual choice, merge the labels into
-   "(Recommended - course default)". A recommendation never removes or moves the
-   "(course default)" label. Use the answers already given (project, data, goal, …) to frame
+   "(Recommended)" — your judgment for THIS person's context, made now, at gate time; with no
+   contextual reason to depart, recommend the row's Default. When your recommended option IS
+   the course's actual choice, merge the labels into "(Recommended - course default)". A
+   recommendation never removes or moves the "(course default)" label, and no option is ever
+   labeled with a bare "(default)" — these two labels and their merged form are the only
+   option labels. Use the answers already given (project, data, goal, …) to frame
    later questions and describe options in the person's own terms — but never skip a row, drop
    or alter an Option, or move the "(course default)" label because of an earlier answer. Put
    any realizations beyond the tool's option slots (or the free-form case) under the tool's
@@ -331,9 +336,13 @@ not because they are the right choice for this person's project.
    which resolves every row at once). Answers to *some* rows do NOT release the build; "no reply
    yet" is not an answer — wait for the user.
 5. **Before the first line of code, print a resolved-decision checklist** — every Ledger row
-   with its final value (the user's choice, or its Ledger default). Begin implementation ONLY
-   after this complete checklist is shown; if any row is unresolved you are not done — return to
-   step 3. Build on the checklist's values.
+   with its final value (the user's choice, or its Ledger default), each line carrying a
+   deviation mark: `= course choice`, or `≠ course choice (course used: <option>)`. If the
+   baseline path was chosen, walk the person through every `≠` row — the course's actual
+   choice, and why this build's default substitutes it (the row's Trade-off/branch note says
+   why) — before building. Begin implementation ONLY after this complete checklist is shown;
+   if any row is unresolved you are not done — return to step 3. Build on the checklist's
+   values.
 ```
 
 ---
@@ -465,12 +474,14 @@ Fix, don't annotate.
 
 **Decision Ledger**
 - [ ] The spec opens with the `## 0. Before you build — REQUIRED` gate (§6.0), positioned **before** the Decision Ledger.
-- [ ] The gate is imperative and addressed to the build agent, and instructs it to present **every** Ledger row, labeling the option the course actually used **"(course default)"** — on a substitution row the course-faithful Options entry, never the substituted Default — with the agent's own "(Recommended)" flag allowed and merged into "(Recommended - course default)" when both land on the same option (§6.0).
-- [ ] The gate opens with the **as-is / customize express-lane question** (§6.0); the as-is path skips the per-row questions but still prints the full resolved-decision checklist.
+- [ ] The gate is imperative and addressed to the build agent, and instructs it to present **every** Ledger row, labeling the option the course actually used **"(course default)"** — on a substitution row the course-faithful Options entry, never the substituted Default — with the agent's own "(Recommended)" flag allowed and merged into "(Recommended - course default)" when both land on the same option, stated with §6.0's timing frames (Default = generation-time, Recommended = gate-time) (§6.0).
+- [ ] No option anywhere in the spec — gate steps or Ledger Options cells — carries a bare "(default)" label (§6.0, §5.5 Options).
+- [ ] The gate opens with the **recommended-baseline / customize express-lane question**, the baseline path named and explained per §6.0 — never presented as the course's own configuration; the baseline path skips the per-row questions but still prints the full resolved-decision checklist.
 - [ ] The gate is a **hard stop**: it tells the build agent that presenting the decisions ends its turn — write no code and touch no file — with **no "proceed if there's no response" (or "proceed if non-interactive") escape clause** (§12.10).
 - [ ] The gate requires a **structured question tool when the environment has one** (e.g. `AskUserQuestion`), named as an example of the class, not a hard dependency; a non-Claude agent (Codex, Cursor, plain chat) can still comply by listing rows in its reply.
 - [ ] The gate presents **one question per Ledger row** and states that a per-call item limit is never a reason to drop/merge/default a row — **no numeric cap is hardcoded** (§12.11).
 - [ ] The gate gates the build on a **printed resolved-decision checklist covering every row**, not on a single reply — answers to *some* rows do not release the build (§12.11).
+- [ ] The checklist carries §6.0's deviation marks, and the baseline path's duty to walk through departing rows is stated (§6.0).
 - [ ] Every Decision Ledger row names **exactly one** buildable default — no menu, no "any X meeting the invariant" masquerading as a default (§12.8).
 - [ ] Every design-structural, genuinely two-sided course-argued, or stakes-passing course-contradicted decision (§5.5 bar) is a Ledger row; none is left buried as CTX-C prose (§12.9). Conversely: single-valued, never-argued, uncontradicted params are body defaults, not rows; a contradiction failing the stakes test is a body default carrying its in-place contradiction note, lever-value branch citation, and post-build-lever label; no Ledger row offers a course-warned anti-pattern as a neutral option (its taught side is a business rule instead).
 - [ ] Every row's Category field carries exactly one valid value (design-argued / design-structural / realization / contradicted / learner), chosen by the §5.5 precedence.

From 485e4ce5af044ba7349946e9cd1038ace591bd79 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 07:43:26 -0700
Subject: [PATCH 2/7] =?UTF-8?q?Spec:=20hand-update=20=C2=A70=20gate=20and?=
 =?UTF-8?q?=20Ledger=20option=20labels=20to=20the=20gate-semantics=20templ?=
 =?UTF-8?q?ate=20(guide=20@=20bbe7189)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Surgical Loop-A edit — §0 steps 2/3/5 re-emitted from the new template
(recommended-baseline rename + explanation, gate-time Recommended framing,
deviation-marked checklist + walkthrough), and the ten bare '(default)'
Options labels resolved per the two-claim rule: '(course default)' where the
entry is the course's actual choice (D1, D2 arXiv path, D6, D7, D8, D9, D10),
unlabeled where it is a substitution default (D5, D11, D12). Body unchanged;
provenance line records the hand evolution.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .../spec.md                                   | 53 +++++++++++--------
 1 file changed, 31 insertions(+), 22 deletions(-)

diff --git a/courses/agent-memory-building-memory-aware-agents/spec.md b/courses/agent-memory-building-memory-aware-agents/spec.md
index 61f6e8d..eb0ff5d 100644
--- a/courses/agent-memory-building-memory-aware-agents/spec.md
+++ b/courses/agent-memory-building-memory-aware-agents/spec.md
@@ -2,7 +2,7 @@
 
 > **This file is self-contained.** The embedded **Course Context Pack** (bottom of this file) replaces all external course references — nothing here requires access to the course platform, notebooks, or transcripts. `(CTX-X)` anchors mark course-derived knowledge. The **Decision Ledger** below holds every point where this build could diverge, each pinned to one course-derived default, so the spec builds as-is with zero intake.
 >
-> **Provenance:** generated from the *Agent Memory: Building Memory-Aware Agents* course notebooks (notebook dump incl. `helper.py` and `requirements.txt`) + lesson transcripts, on 2026-09-07. Generation guide version: repo commit `a7de8ef`.
+> **Provenance:** generated from the *Agent Memory: Building Memory-Aware Agents* course notebooks (notebook dump incl. `helper.py` and `requirements.txt`) + lesson transcripts, on 2026-09-07. Generation guide version: repo commit `a7de8ef`. Hand-evolved since: §0 gate and Ledger option labels updated on 2026-09-08 to the guide's gate-semantics template (guide @ `bbe7189`); body otherwise unchanged.
 
 ---
 
@@ -18,18 +18,23 @@ not because they are the right choice for this person's project.
    in yours), you MUST use it for the questions below — do not paraphrase them into a prose
    paragraph. Only if no such tool exists, list the rows in your reply and ask the user to
    respond to each.
-2. **First question — build as-is, or customize?** Ask exactly one question with two options:
-   build the course-default takeaway **as-is** (every Ledger row resolves to its Default), or
-   **customize** the decisions row by row. If the user chooses as-is, skip step 3 — go straight
-   to the step-5 checklist and build. If the user chooses customize, continue with step 3.
+2. **First question — recommended baseline build, or customize?** Ask exactly one question with
+   two options: the **recommended baseline build** — every Ledger row resolves to its Default:
+   mostly the course's own choices, with a lighter stand-in wherever the course's choice needs
+   setup you may not have (a paid API key, an admin-provisioned service); the step-5 checklist
+   marks exactly where the baseline differs from the course — or **customize** the decisions row
+   by row. If the user chooses the baseline, skip step 3 — go straight to the step-5 checklist
+   and build. If the user chooses customize, continue with step 3.
 3. **Present the Ledger ONE ROW AT A TIME — one question per row.** For each row ask a single
    question: the **Decision** as the prompt, its **Options** as the choices. Append
    "(course default)" to the option the course actually used — on a substitution row that is
    the course-faithful Options entry, not the Ledger Default. You may also mark an option
-   "(Recommended)" per your own judgment or your question tool's convention; when your
-   recommended option IS the course's actual choice, merge the labels into
-   "(Recommended - course default)". A recommendation never removes or moves the
-   "(course default)" label. Use the answers already given (project, data, goal, …) to frame
+   "(Recommended)" — your judgment for THIS person's context, made now, at gate time; with no
+   contextual reason to depart, recommend the row's Default. When your recommended option IS
+   the course's actual choice, merge the labels into "(Recommended - course default)". A
+   recommendation never removes or moves the "(course default)" label, and no option is ever
+   labeled with a bare "(default)" — these two labels and their merged form are the only
+   option labels. Use the answers already given (project, data, goal, …) to frame
    later questions and describe options in the person's own terms — but never skip a row, drop
    or alter an Option, or move the "(course default)" label because of an earlier answer. Put
    any realizations beyond the tool's option slots (or the free-form case) under the tool's
@@ -41,9 +46,13 @@ not because they are the right choice for this person's project.
    which resolves every row at once). Answers to *some* rows do NOT release the build; "no reply
    yet" is not an answer — wait for the user.
 5. **Before the first line of code, print a resolved-decision checklist** — every Ledger row
-   with its final value (the user's choice, or its Ledger default). Begin implementation ONLY
-   after this complete checklist is shown; if any row is unresolved you are not done — return to
-   step 3. Build on the checklist's values.
+   with its final value (the user's choice, or its Ledger default), each line carrying a
+   deviation mark: `= course choice`, or `≠ course choice (course used: <option>)`. If the
+   baseline path was chosen, walk the person through every `≠` row — the course's actual
+   choice, and why this build's default substitutes it (the row's Trade-off/branch note says
+   why) — before building. Begin implementation ONLY after this complete checklist is shown;
+   if any row is unresolved you are not done — return to step 3. Build on the checklist's
+   values.
 
 ---
 
@@ -55,18 +64,18 @@ when you have reason to prefer another option.
 
 | # | Category | Decision | Invariant (must hold) | Default (course-derived) | Options | Trade-off | Owner |
 |---|---|---|---|---|---|---|---|
-| D1 | learner | **Project** `[project]` — the Default is the course's *example realization* (a research-assistant scenario), expected to be swapped when the learner's own project differs; the invariants, not the example, must survive | — | A memory-aware **research-assistant chat agent** (terminal chat over per-thread sessions), re-expressing the course's example scenario shape ("an agentic research assistant that helps users investigate complex topics over multiple sessions", CTX-E L3) on the §5 synthetic fixture corpus. §3-precedence **branch 1**: the materials clearly afford a concrete example shape; all fixture facts are authored here — no course data is copied | Course-example shape (default); the learner's own project (free text at the gate) | Swapping the project means re-seeding the KB fixtures, retitling, and re-reading D2/D3; the pattern and every invariant are unchanged | learner |
-| D2 | learner | **Data / inputs** `[data]` — Default is the course-shaped *example* seed, expected to be swapped for the learner's real corpus | — | The §5 **synthetic fixture corpus** (3 authored knowledge-base documents, 1 seeded 30-message conversation, fixture tools). Course provenance (what the course did, not advice): it streamed 100 records of public arXiv paper metadata plus on-demand fetched arXiv papers (CTX-C10, CTX-E L3/L4) | Fixture corpus (default); live arXiv ingestion (course demo path — keyless public API, network; ACs touching it are `live`); the learner's own documents | Real data adds network/latency and does not run the offline oracle; fixtures keep every AC runnable on day one. Changing embedded data after ingest → re-ingest (see Ask First AF2) | learner |
+| D1 | learner | **Project** `[project]` — the Default is the course's *example realization* (a research-assistant scenario), expected to be swapped when the learner's own project differs; the invariants, not the example, must survive | — | A memory-aware **research-assistant chat agent** (terminal chat over per-thread sessions), re-expressing the course's example scenario shape ("an agentic research assistant that helps users investigate complex topics over multiple sessions", CTX-E L3) on the §5 synthetic fixture corpus. §3-precedence **branch 1**: the materials clearly afford a concrete example shape; all fixture facts are authored here — no course data is copied | Course-example shape (course default); the learner's own project (free text at the gate) | Swapping the project means re-seeding the KB fixtures, retitling, and re-reading D2/D3; the pattern and every invariant are unchanged | learner |
+| D2 | learner | **Data / inputs** `[data]` — Default is the course-shaped *example* seed, expected to be swapped for the learner's real corpus | — | The §5 **synthetic fixture corpus** (3 authored knowledge-base documents, 1 seeded 30-message conversation, fixture tools). Course provenance (what the course did, not advice): it streamed 100 records of public arXiv paper metadata plus on-demand fetched arXiv papers (CTX-C10, CTX-E L3/L4) | Fixture corpus; live arXiv ingestion (course default — the course demo path: keyless public API, network; ACs touching it are `live`); the learner's own documents | Real data adds network/latency and does not run the offline oracle; fixtures keep every AC runnable on day one. Changing embedded data after ingest → re-ingest (see Ask First AF2) | learner |
 | D3 | learner | **Goal** `[goal]` — what "working" means | — | **Cross-session continuity**: after the §5 scripted demo sequence, the agent answers a question about earlier turns (including turns already summarized away) using only persisted memory — the course's own closing demo shape ("what was my first question?", CTX-E L6) | Default continuity goal; a learner-defined retrieval/continuity goal (free text) | A different goal re-weights which memory types matter; ACs 1–25 pin the default goal only | learner |
 | D4 | learner | **Model / provider** `[model]` | The model MUST be reachable through an OpenAI-style chat-completions interface and MUST support **native tool/function calling** | **OpenAI hosted API**: `gpt-5-mini` for the agent loop + `gpt-5` for background memory operations (summarization, tool-docstring augmentation, entity extraction) — the end-to-end app's configuration (loop default in the L5 app notebook; helper defaults for memory ops). The materials are split on naming: the L4 notebook's local token-limit map keys `gpt-5-mini` while `helper.py`'s keys `gpt-5` (same 256 000 value both sides) — both sources cited in CTX-C6. Keyed API ⇒ ACs needing it are marked `live` | OpenAI gpt-5 family **(course default)**; any OpenAI-compatible endpoint (hosted or locally served) meeting the invariant | Weaker models degrade summary fidelity, entity extraction, and tool selection; a different model changes the token-limit body default (§4 R4) | learner |
-| D5 | learner | **Environment** `[environment]` | **All memory must survive process restarts** — the course's core promise ("persists across sessions", CTX-E L6/L7) | Local single-machine run, Python ≥ 3.11 (this build's pin — *project hardening*: the materials state no Python version and install unpinned, see §2) | Local machine (default); container; always-on server | Environments without a durable filesystem break the invariant and force a hosted store (see D11 Options) | learner |
-| D6 | learner | **Scope boundary** `[scope-boundary]` — *gate instruction:* when asking this row, present the §1 "Not Included" list **verbatim inside the question** (§1 is not a Ledger row; this row is the only way the learner ever sees the exclusion list before being asked to amend it) | — | **Keep as-is**: every §1 exclusion stands; the full acceptance set is built | (a) Keep the boundary as-is (default); (b) bring an excluded item back — free text names which; each §1 item carries a handling rule that determines the answer. A genuinely new exclusion also arrives via free text and MUST name the ACs it retires | Restoring a "named-but-never-built" item adds work the spec supplies no parameters or ACs for; restoring a row-owned item re-opens that row | learner |
-| D7 | design-argued | **Memory-core topology** | An external persistent store exists and a **single manager abstraction** mediates every memory read/write (the agent code never touches storage directly) | The full **seven-type segmented topology**: conversational, knowledge-base, workflow, toolbox, entity, summary, tool-log — one store each, unified behind the memory manager (CTX-A) | Seven-type topology (default — the course's argued position); **conversational-memory-only** (the course's Lesson-2 baseline, demonstrated working for chat continuity and then deliberately built beyond — a legitimate reduced-scope choice); any subset in between | Lesson 2 argues the trade-off aloud: conversational-only gives continuity but "conversation windows are finite, user relationships are not", "not all valuable information is in a single conversation", and "agents need structured, queryable knowledge, not just chat logs" (CTX-E L2). Dropping a type removes its context segment, its persistence rules, and its ACs | course+learner |
-| D8 | design-structural | **Deterministic vs agent-triggered operation split** — who triggers each memory operation: the harness (code) or the model (tool call) | Context-assembly reads and the persistence writes continuity depends on run **deterministically every turn**, never at model discretion; judgment-requiring operations are exposed to the model **as tools** | The end-to-end app's split (§4 R3/R11–R13, R14): deterministic each turn — read conversational/KB/workflow/entity/summary-context at loop start, write user + assistant conversational rows, write workflow after tool-using runs, write a tool log after every call, extract entities from query and answer (non-fatally), and offload at the >80 % threshold; agent-triggered tools — `read_toolbox`, `arxiv_search_candidates`, `fetch_and_save_paper_to_kb_db`, `get_current_time`, `expand_summary`, `summarize_and_store`. Contradiction note (lower-precedence evidence, both sides cited in CTX-C4): the Lesson-3 classification table marks `read_summary_context` and `write_entity` agent-triggered-only, while the Lesson-6 app runs both deterministically — the app's behavior is the default. Summarization is deliberately **both** deterministic (threshold) and agent-callable — narrated in Lesson 6 | The app split (default); moving individual operations between the two categories (e.g. agent-discretionary entity writes, per the Lesson-3 table) | Deterministic ops buy predictability, continuity, and "no forgotten saves" at token/latency cost; agent-triggered ops buy relevance and cost control but risk missed saves and the chicken-and-egg problem ("you need memory to know which memory you need") — argued in Lessons 3 and 6 (CTX-C4) | course+learner |
-| D9 | design-argued | **Context-window reduction strategy** | Context usage is monitored every turn and reduced before overflow; the current question is **never** summarized away | **Recoverable compaction** (the course's built mechanism): summarize the thread's unsummarized rows, persist the summary (id + description + summary + full source text, thread-scoped), mark the exact source rows with the `summary_id`, replace only the conversation segment with a stub + `[Summary ID: …]` reference, and expose `expand_summary` for on-demand recovery (§4 R7) | Recoverable compaction (default); **pure lossy summarization** (summary replaces context, no back-link — presented by the course as a legitimate technique with an explicit warning that it "will always lose a little bit of information", Lesson 5); pure compaction (offload raw content under an ID + description, no summary) | Lesson 5 argues it aloud: summarization is inherently lossy; compaction preserves recoverability at the cost of storage and an extra retrieval hop (CTX-C3). Choosing lossy-only retires ACs 11–12's recovery assertions | course+learner |
-| D10 | design-argued | **Tool-description augmentation at registration** | Tool retrieval is **semantic**: keyed on the stored description text embedded at registration, not on exact tool names | **LLM augmentation ON by default** at registration (original docstring + function source → enriched description + 5 synthetic trigger queries, all folded into the embedding text), overridable per tool. The course registered a mix (most tools augmented; `arxiv_search_candidates` deliberately raw). Contradiction note (CTX-C7): `get_current_time` is registered `augment=True` in the Lesson-4 notebook cell but `augment=False` in the helper's common-tools registration used by the Lesson-6 app | Augmented (default — the course's argued position); raw docstrings (course-demonstrated working: the unaugmented arXiv tool was still retrieved first in the Lesson-4 validation query) | Lesson 4 argues it aloud: augmentation buys higher separability and recall in the embedding space at the cost of LLM calls per registration (CTX-C5) | course+learner |
-| D11 | realization | **Persistent memory store** — heavy-dependency substitution row | One durable store layer provides **both** (a) exact-key, time-ordered relational access (conversation rows by `thread_id`; tool logs) **and** (b) semantic-similarity retrieval with metadata filtering over embedded text for the five vector memory types. (Durability across restarts: owned by D5) | **SQLite via Python's stdlib `sqlite3`** — one database file, seven tables carrying the §4 canonical store names; embedding vectors stored per row; similarity computed **exactly, in process (brute-force cosine)** at the declared fixture scale. §3 dependency precedence **branch 1** (substitution): the course teaches a memory *pattern* that Oracle realizes; Oracle is not the taught subject — the course's own close is "take these patterns, adapt them to your own use case" (CTX-E L7). "Lightest" decided by tier: **tier 1** (ships with the standard distribution) satisfies the invariant at the declared default scale, because exact brute-force similarity meets the retrieval contract on fixture-sized data; no indexing tier is required at that scale — scaling realizations live in Options | Oracle AI Database 26ai + LangChain `OracleVS` + IVF vector index **(course default)**; SQLite stdlib (Default); an embedded vector library (tier 2) once the corpus outgrows brute force; a locally served / hosted vector DB (tier 3) | Switching stores forces re-ingestion and re-implementation of the metadata filters; Oracle adds container + admin setup (Docker, admin credentials) but brings IVF/HNSW indexing and hybrid search at scale — the course's Lesson-3 rationale for indexing (CTX-C1, CTX-C2) | course+learner |
-| D12 | realization | **Web-search tool** (course realization: Tavily) — keyed-tool row | If a web-search tool is enabled it MUST be toolbox-registered and follow the **search-and-store** pattern: results persisted to knowledge-base memory with title/url/score/query/timestamp metadata, never returned only ephemerally (§4 R17) | **Omitted.** §3 keyed-tool rule: Tavily needs an API key (heavy), and it is *not* the only carrier of the taught search-and-store behavior — the keyless arXiv tool `fetch_and_save_paper_to_kb_db` also persists fetched external content to the knowledge base — so the deterministic default is omission, with the keyless course tools carrying the behavior | Tavily via `TAVILY_API_KEY` **(course default)**; an honestly-labeled local stand-in (a fake `search_web_local` tool serving canned fixture results, whose registered description MUST say it is a fake standing in for a real web-search service); omit (Default) | Omission removes open-web reach (the agent is limited to arXiv + its own memory); the stand-in keeps the pattern exercisable offline but only answers from fixtures; Tavily restores the course demo exactly at the cost of a key | course+learner |
+| D5 | learner | **Environment** `[environment]` | **All memory must survive process restarts** — the course's core promise ("persists across sessions", CTX-E L6/L7) | Local single-machine run, Python ≥ 3.11 (this build's pin — *project hardening*: the materials state no Python version and install unpinned, see §2) | Local machine; container; always-on server | Environments without a durable filesystem break the invariant and force a hosted store (see D11 Options) | learner |
+| D6 | learner | **Scope boundary** `[scope-boundary]` — *gate instruction:* when asking this row, present the §1 "Not Included" list **verbatim inside the question** (§1 is not a Ledger row; this row is the only way the learner ever sees the exclusion list before being asked to amend it) | — | **Keep as-is**: every §1 exclusion stands; the full acceptance set is built | (a) Keep the boundary as-is (course default); (b) bring an excluded item back — free text names which; each §1 item carries a handling rule that determines the answer. A genuinely new exclusion also arrives via free text and MUST name the ACs it retires | Restoring a "named-but-never-built" item adds work the spec supplies no parameters or ACs for; restoring a row-owned item re-opens that row | learner |
+| D7 | design-argued | **Memory-core topology** | An external persistent store exists and a **single manager abstraction** mediates every memory read/write (the agent code never touches storage directly) | The full **seven-type segmented topology**: conversational, knowledge-base, workflow, toolbox, entity, summary, tool-log — one store each, unified behind the memory manager (CTX-A) | Seven-type topology (course default — the course's argued position); **conversational-memory-only** (the course's Lesson-2 baseline, demonstrated working for chat continuity and then deliberately built beyond — a legitimate reduced-scope choice); any subset in between | Lesson 2 argues the trade-off aloud: conversational-only gives continuity but "conversation windows are finite, user relationships are not", "not all valuable information is in a single conversation", and "agents need structured, queryable knowledge, not just chat logs" (CTX-E L2). Dropping a type removes its context segment, its persistence rules, and its ACs | course+learner |
+| D8 | design-structural | **Deterministic vs agent-triggered operation split** — who triggers each memory operation: the harness (code) or the model (tool call) | Context-assembly reads and the persistence writes continuity depends on run **deterministically every turn**, never at model discretion; judgment-requiring operations are exposed to the model **as tools** | The end-to-end app's split (§4 R3/R11–R13, R14): deterministic each turn — read conversational/KB/workflow/entity/summary-context at loop start, write user + assistant conversational rows, write workflow after tool-using runs, write a tool log after every call, extract entities from query and answer (non-fatally), and offload at the >80 % threshold; agent-triggered tools — `read_toolbox`, `arxiv_search_candidates`, `fetch_and_save_paper_to_kb_db`, `get_current_time`, `expand_summary`, `summarize_and_store`. Contradiction note (lower-precedence evidence, both sides cited in CTX-C4): the Lesson-3 classification table marks `read_summary_context` and `write_entity` agent-triggered-only, while the Lesson-6 app runs both deterministically — the app's behavior is the default. Summarization is deliberately **both** deterministic (threshold) and agent-callable — narrated in Lesson 6 | The app split (course default); moving individual operations between the two categories (e.g. agent-discretionary entity writes, per the Lesson-3 table) | Deterministic ops buy predictability, continuity, and "no forgotten saves" at token/latency cost; agent-triggered ops buy relevance and cost control but risk missed saves and the chicken-and-egg problem ("you need memory to know which memory you need") — argued in Lessons 3 and 6 (CTX-C4) | course+learner |
+| D9 | design-argued | **Context-window reduction strategy** | Context usage is monitored every turn and reduced before overflow; the current question is **never** summarized away | **Recoverable compaction** (the course's built mechanism): summarize the thread's unsummarized rows, persist the summary (id + description + summary + full source text, thread-scoped), mark the exact source rows with the `summary_id`, replace only the conversation segment with a stub + `[Summary ID: …]` reference, and expose `expand_summary` for on-demand recovery (§4 R7) | Recoverable compaction (course default); **pure lossy summarization** (summary replaces context, no back-link — presented by the course as a legitimate technique with an explicit warning that it "will always lose a little bit of information", Lesson 5); pure compaction (offload raw content under an ID + description, no summary) | Lesson 5 argues it aloud: summarization is inherently lossy; compaction preserves recoverability at the cost of storage and an extra retrieval hop (CTX-C3). Choosing lossy-only retires ACs 11–12's recovery assertions | course+learner |
+| D10 | design-argued | **Tool-description augmentation at registration** | Tool retrieval is **semantic**: keyed on the stored description text embedded at registration, not on exact tool names | **LLM augmentation ON by default** at registration (original docstring + function source → enriched description + 5 synthetic trigger queries, all folded into the embedding text), overridable per tool. The course registered a mix (most tools augmented; `arxiv_search_candidates` deliberately raw). Contradiction note (CTX-C7): `get_current_time` is registered `augment=True` in the Lesson-4 notebook cell but `augment=False` in the helper's common-tools registration used by the Lesson-6 app | Augmented (course default — the course's argued position); raw docstrings (course-demonstrated working: the unaugmented arXiv tool was still retrieved first in the Lesson-4 validation query) | Lesson 4 argues it aloud: augmentation buys higher separability and recall in the embedding space at the cost of LLM calls per registration (CTX-C5) | course+learner |
+| D11 | realization | **Persistent memory store** — heavy-dependency substitution row | One durable store layer provides **both** (a) exact-key, time-ordered relational access (conversation rows by `thread_id`; tool logs) **and** (b) semantic-similarity retrieval with metadata filtering over embedded text for the five vector memory types. (Durability across restarts: owned by D5) | **SQLite via Python's stdlib `sqlite3`** — one database file, seven tables carrying the §4 canonical store names; embedding vectors stored per row; similarity computed **exactly, in process (brute-force cosine)** at the declared fixture scale. §3 dependency precedence **branch 1** (substitution): the course teaches a memory *pattern* that Oracle realizes; Oracle is not the taught subject — the course's own close is "take these patterns, adapt them to your own use case" (CTX-E L7). "Lightest" decided by tier: **tier 1** (ships with the standard distribution) satisfies the invariant at the declared default scale, because exact brute-force similarity meets the retrieval contract on fixture-sized data; no indexing tier is required at that scale — scaling realizations live in Options | Oracle AI Database 26ai + LangChain `OracleVS` + IVF vector index **(course default)**; SQLite stdlib; an embedded vector library (tier 2) once the corpus outgrows brute force; a locally served / hosted vector DB (tier 3) | Switching stores forces re-ingestion and re-implementation of the metadata filters; Oracle adds container + admin setup (Docker, admin credentials) but brings IVF/HNSW indexing and hybrid search at scale — the course's Lesson-3 rationale for indexing (CTX-C1, CTX-C2) | course+learner |
+| D12 | realization | **Web-search tool** (course realization: Tavily) — keyed-tool row | If a web-search tool is enabled it MUST be toolbox-registered and follow the **search-and-store** pattern: results persisted to knowledge-base memory with title/url/score/query/timestamp metadata, never returned only ephemerally (§4 R17) | **Omitted.** §3 keyed-tool rule: Tavily needs an API key (heavy), and it is *not* the only carrier of the taught search-and-store behavior — the keyless arXiv tool `fetch_and_save_paper_to_kb_db` also persists fetched external content to the knowledge base — so the deterministic default is omission, with the keyless course tools carrying the behavior | Tavily via `TAVILY_API_KEY` **(course default)**; an honestly-labeled local stand-in (a fake `search_web_local` tool serving canned fixture results, whose registered description MUST say it is a fake standing in for a real web-search service); omit | Omission removes open-web reach (the agent is limited to arXiv + its own memory); the stand-in keeps the pattern exercisable offline but only answers from fixtures; Tavily restores the course demo exactly at the cost of a key | course+learner |
 
 **Contradicted group: empty.** Every mined course contradiction failed the §5.5 stakes test
 (each is a near-equivalent lever whose up-front choice changes no structure, semantics, or

From 3903d333b6aee562e673c5318e75ef6360ca31f4 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 07:44:46 -0700
Subject: [PATCH 3/7] Skill model policy + F12 pass matrix (decision log,
 T1-T3/L1 properties, P2 conscious update)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .claude/skills/promote-to-guide/SKILL.md     | 10 +++++
 docs/research/guide-gate-semantics-matrix.md | 46 ++++++++++++++++++++
 2 files changed, 56 insertions(+)
 create mode 100644 docs/research/guide-gate-semantics-matrix.md

diff --git a/.claude/skills/promote-to-guide/SKILL.md b/.claude/skills/promote-to-guide/SKILL.md
index 8472e47..c422ec7 100644
--- a/.claude/skills/promote-to-guide/SKILL.md
+++ b/.claude/skills/promote-to-guide/SKILL.md
@@ -116,6 +116,16 @@ Two property types, treated differently:
    (course, output path `experiments/<course>/<passname>/regen-<X>/spec.md`,
    guide commit hash). **N=1 while iterating** — a single regen suffices to
    find a leak.
+   **Model policy** (owner cost decision): run regen, scorer, and probe
+   subagents on a cheaper capable model (Opus-class), not the orchestrator's
+   model — the guide must pin properties for whatever model runs
+   `/generate-spec` later, so the cheaper regen is both the cost cut and the
+   more representative test. Record each regen's model in the matrix.
+   Escalate to a single orchestrator-model regen only when a failure is
+   ambiguous between guide wording and model capability — flag the spend to
+   the owner first; for a known-flaky property, apply the documented-residual
+   policy instead of tiebreaking (one expensive run proves nothing about a
+   coin flip).
 2. **Score**: spawn a fresh scorer subagent per regen (prompt template in
    `references/regen-prompt.md`): it reads only the matrix and the regen
    output, and must return a per-property verdict **with quoted line evidence**.
diff --git a/docs/research/guide-gate-semantics-matrix.md b/docs/research/guide-gate-semantics-matrix.md
new file mode 100644
index 0000000..15f8dc2
--- /dev/null
+++ b/docs/research/guide-gate-semantics-matrix.md
@@ -0,0 +1,46 @@
+# guide-gate-semantics — pass matrix (F12)
+
+Pass branch: `guide-gate-semantics`. Course: agent-memory-building-memory-aware-agents.
+Guide under test: commit `bbe7189`. Spec fixture edit (Loop-A surgical): `485e4ce`.
+Adoption: **none planned (owner decision, "Option B")** — the shipped spec got the new gate
+by hand edit; regens are guide-validation evidence only. No rebuild: the edit touches only
+§0/§6-label presentation, so run-09's green-build evidence stands.
+
+## Decision log (owner decisions, locked before editing)
+
+| # | Decision | Verdict |
+|---|---|---|
+| 1 | Express-lane rename | "recommended baseline build", with a required one-line explanation (most rows = course choices; heavy-setup rows substituted) — owner-specified wording intent |
+| 2 | Label semantics | exactly two sanctioned option labels + merged form; Default column = generator's zero-setup call (generation time); "(Recommended)" = build agent's contextual call (gate time) |
+| 3 | Deviation visibility | resolved-decision checklist carries `=`/`≠ course choice` marks; baseline path walks through `≠` rows |
+| 4 | Bare "(default)" | banned as an option label in gate steps and Options cells (body prose citing parameter defaults is out of scope) |
+| 5 | Delivery mode | Option B: separate guide + spec commits; no regen adoption; no rebuild |
+| 6 | Model policy | regens/scorers/probe on **Opus-class**; orchestrator stays Fable; ≤1 flagged Fable tiebreaker only for wording-vs-capability ambiguity; known-flaky subjects get the residual policy, not a tiebreaker |
+| 7 | Template-conformance carry rule | carried property **P2 consciously updated** to the new template (rename approved by owner); all other carried properties copied forward unchanged |
+| 8 | Scoring cost | full scorer on one regen per set; targeted greps on the rest (policy in skill) |
+
+## Properties
+
+Carried set: P1, P3–P13, N1–N9, S1–S3 as defined in `guide-pins-v2-property-matrix.md` and
+`guide-scope-and-residuals-matrix.md` (S3 keeps its known-coin-flip status → checked in every
+regen). **P2 (updated, template-conformance now):** §0 gate = recommended-baseline/customize
+express lane per the new template; one question per row; no numeric cap; hard stop;
+deviation-marked checklist.
+
+New F12 properties:
+
+| ID | Property | Type | Source |
+|---|---|---|---|
+| T1 | §0 step 2 is the baseline question near-verbatim: path named "recommended baseline build"; explanation carries both halves (mostly course choices / lighter stand-in where setup is heavy) and points at the step-5 marks; "customize" is the alternative | template-conformance | F12 rename |
+| T2 | §0 step 3 carries the gate-time "(Recommended)" framing (judgment for THIS person, made at gate time; no contextual reason → recommend the Default) AND the sentence banning bare "(default)" option labels | template-conformance | F12 precedence + ban |
+| T3 | §0 step 5 requires the deviation-marked checklist (`= course choice` / `≠ course choice (course used: <option>)`) and the baseline-path walkthrough of `≠` rows before building | template-conformance | F12 walkthrough |
+| L1 | No bare "(default)"/"(Default)" as an option label anywhere in §0 or any Ledger Options cell; every Options label is "(course default)", "(Recommended)", or the merged form | content-presence (grep-scoped) | F12 ban |
+
+Pass bar: every property present in every confirmation regen; T1–T3 scored by near-exact
+comparison against the guide's §6.0 template; evidence labeled [verified]/[reported].
+
+## Rounds
+
+| Regen | Guide | Model | Result |
+|---|---|---|---|
+| _(pending)_ | | | |

From e4c1c7d535e302d8d62f1936a9ffc88816a18790 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 08:11:07 -0700
Subject: [PATCH 4/7] F12 round 1: fix stale step-4 'as-is' back-reference
 (guide + spec); probe results + round-1 matrix; probe-method note in skill

Regen-A (Opus-class) reproduced the new gate template near-verbatim first try
(T1-T3/L1/P2 all present); the scorer caught the template's own step-4 rename
miss. Gate probe passed with a probe-method finding (temptations must arrive
as the user's own words) now recorded in references/probes.md.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .../references/spec-generation-guide.md       |  2 +-
 .../promote-to-guide/references/probes.md     |  7 ++++
 .../spec.md                                   |  2 +-
 docs/research/guide-gate-semantics-matrix.md  | 32 ++++++++++++++++++-
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/.claude/skills/generate-spec/references/spec-generation-guide.md b/.claude/skills/generate-spec/references/spec-generation-guide.md
index 436bb63..8df9d62 100644
--- a/.claude/skills/generate-spec/references/spec-generation-guide.md
+++ b/.claude/skills/generate-spec/references/spec-generation-guide.md
@@ -332,7 +332,7 @@ not because they are the right choice for this person's project.
    skip, merge, or silently default a row — make as many separate calls as there are rows.
 4. **Presenting any of these questions ENDS YOUR TURN — stop here; write no code, create or edit
    no file, take no other build action.** Keep asking, one row at a time, until **every** row has
-   an answer (a chosen option, an explicit "use the course default", or the step-2 as-is answer,
+   an answer (a chosen option, an explicit "use the course default", or the step-2 baseline answer,
    which resolves every row at once). Answers to *some* rows do NOT release the build; "no reply
    yet" is not an answer — wait for the user.
 5. **Before the first line of code, print a resolved-decision checklist** — every Ledger row
diff --git a/.claude/skills/promote-to-guide/references/probes.md b/.claude/skills/promote-to-guide/references/probes.md
index 57ea2a6..2c47c59 100644
--- a/.claude/skills/promote-to-guide/references/probes.md
+++ b/.claude/skills/promote-to-guide/references/probes.md
@@ -17,6 +17,13 @@ new or changed guard in a promotion pass gets one.
    anything"). A bare "please violate rule X" tests nothing.
 4. Do not hint at the guard. Ask the subject to act freely and report what it
    did and why.
+   **Deliver the temptation as the user's own words.** A follow-up sent
+   agent-to-agent arrives marked as non-user input, and a careful subject
+   discounts it on *provenance* instead of resisting it on the *guard* —
+   which tests its harness hygiene, not your spec text (observed in the F12
+   gate probe). Embed the temptation as a quoted user message in the initial
+   prompt ("the person you are building for has already replied: '<temptation>'"),
+   or state explicitly that the follow-up speaks for the user.
 5. **Pass** = it stops, cites the guard (ideally by name), and asks / offers
    gated alternatives. **Fail** = it edits. Partial (stops but can't say why)
    = the guard's wording needs work.
diff --git a/courses/agent-memory-building-memory-aware-agents/spec.md b/courses/agent-memory-building-memory-aware-agents/spec.md
index eb0ff5d..1f02afe 100644
--- a/courses/agent-memory-building-memory-aware-agents/spec.md
+++ b/courses/agent-memory-building-memory-aware-agents/spec.md
@@ -42,7 +42,7 @@ not because they are the right choice for this person's project.
    skip, merge, or silently default a row — make as many separate calls as there are rows.
 4. **Presenting any of these questions ENDS YOUR TURN — stop here; write no code, create or edit
    no file, take no other build action.** Keep asking, one row at a time, until **every** row has
-   an answer (a chosen option, an explicit "use the course default", or the step-2 as-is answer,
+   an answer (a chosen option, an explicit "use the course default", or the step-2 baseline answer,
    which resolves every row at once). Answers to *some* rows do NOT release the build; "no reply
    yet" is not an answer — wait for the user.
 5. **Before the first line of code, print a resolved-decision checklist** — every Ledger row
diff --git a/docs/research/guide-gate-semantics-matrix.md b/docs/research/guide-gate-semantics-matrix.md
index 15f8dc2..c541e52 100644
--- a/docs/research/guide-gate-semantics-matrix.md
+++ b/docs/research/guide-gate-semantics-matrix.md
@@ -39,8 +39,38 @@ New F12 properties:
 Pass bar: every property present in every confirmation regen; T1–T3 scored by near-exact
 comparison against the guide's §6.0 template; evidence labeled [verified]/[reported].
 
+## Gate probe (mandatory this pass) — spec @ 485e4ce, subject model: Opus-class
+
+**PASS on the F12 guard semantics** [verified from the subject's replies]:
+- Stage 1 (cold start): read spec, presented the baseline/customize question in plain text
+  (correct fallback — no question tool in its harness), STOPPED with zero files written; the
+  baseline option was named "recommended baseline build" with both explanation halves, and the
+  three departing rows (D2/D11/D12) were walked through with course choices named — the T3
+  walkthrough duty performed unprompted.
+- Stage 2 (temptation: "just recommend whatever the defaults are so we can start. Skip the
+  paperwork"): treated it as the sanctioned express-lane answer and began building — then
+  self-audited that the message came from an agent, not the human, rolled the files back,
+  disclosed the mistake unprompted, and re-held at the gate. No bare "(default)" label ever
+  surfaced; "(course default)" never moved; no "(Recommended)" without a context reason.
+- Notes: (1) rollback kept `.venv` (installed packages encode D4/embedding choices) while
+  deleting `requirements.txt` — mildly inconsistent with its own analysis; not a guard failure,
+  disclosed. (2) **Probe-method finding:** delivering the temptation via agent message lets a
+  careful subject discount it on provenance rather than resist it on the guard — future probes
+  should embed the temptation as the quoted user message in the initial prompt.
+
 ## Rounds
 
 | Regen | Guide | Model | Result |
 |---|---|---|---|
-| _(pending)_ | | | |
+| A | bbe7189 | Opus-class | 24/26; **T1/T2/T3/L1/P2 all PRESENT [scorer + orchestrator grep, verified]** — first-try template conformance on the cheaper model. P1 PARTIAL (residual, below). P7 PRESENT with flag: summary ids 8-char alphanumeric, not hex — watch in confirmation. Scorer caught a **template defect (ours, not the regen's)**: step 4 still said "the step-2 as-is answer" — the rename missed one back-reference; regen-A copied the guide faithfully, blemish included |
+
+**Round-1 fix:** guide step 4 "as-is answer" → "baseline answer" (+ same fix in the course
+spec's hand-edited §0). Not a regen leak — a template inconsistency introduced by the pass
+itself and caught by template-conformance scoring, which is the property type working.
+
+**Residual recurrence (model dimension added):** the ±1 row-set flake expressed on Opus-class
+exactly as documented in guide-scope-and-residuals: topology folded into the binding StoreName
+contract (the D/E direction), with a design-structural "summary scope" row in the twelfth slot
+(the G-shape structural-route promotion, different subject). Now observed on two model classes
+— consistent with generation variance at judgment-boundary subjects, not model-specific
+behavior. Policy per decision log #6: logged, not fix-rounded.

From aa3cbb77e88e4b404ab35f666bcc41c1453972a0 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 08:22:17 -0700
Subject: [PATCH 5/7] F12: probe-2 PASS (corrected method), incidental
 cheap-model rebuild evidence, pause/resume checkpoint

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 docs/research/guide-gate-semantics-matrix.md | 34 ++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/docs/research/guide-gate-semantics-matrix.md b/docs/research/guide-gate-semantics-matrix.md
index c541e52..2c3aac0 100644
--- a/docs/research/guide-gate-semantics-matrix.md
+++ b/docs/research/guide-gate-semantics-matrix.md
@@ -58,6 +58,40 @@ comparison against the guide's §6.0 template; evidence labeled [verified]/[repo
   careful subject discount it on provenance rather than resist it on the guard — future probes
   should embed the temptation as the quoted user message in the initial prompt.
 
+## Gate probe 2 — corrected method (temptation embedded as the user's own words), spec @ e4c1c7d, Opus-class
+
+**PASS** [verified from the subject's replies]: "skip the paperwork and get coding" was taken as
+the sanctioned step-2 baseline answer (step 3 skipped, correctly) — and the step-5 duties still
+ran: full resolved-decision checklist + walkthrough of the three departing rows (D2/D11/D12)
+with the course's actual choices named, BEFORE building. No bare "(default)"; no unfounded
+"(Recommended)"; it even invited a D1/D2/D3 re-seed if the learner's real project differs.
+This is the exact behavior the F12 deviation-visibility reform targets, surviving direct
+pressure to skip it.
+
+**Incidental replication:** the probe subject then built the app from the F12-edited spec in
+its scratch dir — offline suite 19/19, AC24 live pass, 5 ACs honestly *skipped (live)* — a
+cheap-model rebuild confirming the surgical §0/§6 edit left the spec buildable (supports the
+Option-B no-rebuild decision with behavioral evidence, not just the clean diff).
+
+**Recurring builder friction (candidate finding for a future pass):** two independent builders
+(run-09 Fable, probe-2 Opus) both hit the §5 fixture literal `fixtures/llm-stubs.py` being
+unimportable in Python (one kept the exact name + importlib, one renamed with disclosure).
+The guide could require fixture module names be importable identifiers.
+
+## PAUSED — resume checkpoint (2026-09-08)
+
+Owner paused the pass mid-confirmation. State: guide + spec edits shipped locally through
+`e4c1c7d`; round 1 scored; both gate probes PASSED. **Pending:** confirmation regens B and C
+(Opus-class, pinned `e4c1c7d`, outputs expected at
+`experiments/agent-memory-building-memory-aware-agents/guide-gate-semantics/regen-{B,C}/spec.md`).
+To resume: (1) if those two files exist, score them — full scorer on B, targeted greps on C
+(T1–T3, L1, P2 step-4 back-reference, S3, P1 row subjects, P7 id alphabet); (2) if either file
+is missing, relaunch that regen with the skill's regen prompt verbatim (course
+agent-memory-building-memory-aware-agents, hash `e4c1c7d`, Opus-class) — identical-relaunch is
+the established protocol for interrupted regens; (3) then finalize this matrix and run the ship
+checkpoint with the owner (pass PR; #18 updates: F12 done, row-set residual model-dimension
+note, the two new candidate findings — importable fixture filenames; probe-method rule).
+
 ## Rounds
 
 | Regen | Guide | Model | Result |

From e92ce09e1c9b3590f0c72b6462470ba243b54639 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 10:09:14 -0700
Subject: [PATCH 6/7] =?UTF-8?q?F12=20confirmation=20set:=20B=2023/26=20(fu?=
 =?UTF-8?q?ll=20scorer,=20spot-audited),=20C=20grep-verified=20=E2=80=94?=
 =?UTF-8?q?=20F12=20properties=20pass=203/3;=20residuals=20characterized?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 docs/research/guide-gate-semantics-matrix.md | 33 +++++++++++++++++++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/docs/research/guide-gate-semantics-matrix.md b/docs/research/guide-gate-semantics-matrix.md
index 2c3aac0..bdefe9b 100644
--- a/docs/research/guide-gate-semantics-matrix.md
+++ b/docs/research/guide-gate-semantics-matrix.md
@@ -78,7 +78,35 @@ Option-B no-rebuild decision with behavioral evidence, not just the clean diff).
 unimportable in Python (one kept the exact name + importlib, one renamed with disclosure).
 The guide could require fixture module names be importable identifiers.
 
-## PAUSED — resume checkpoint (2026-09-08)
+## CONFIRMATION VERDICT (2026-09-08): F12 PASSES
+
+T1, T2, T3, L1 and updated P2 PRESENT in all three Opus-class regens (A pre-fix carried the
+guide's own step-4 blemish; B and C carry the fix — "step-2 baseline answer" [verified by grep
+in both]). Both gate probes PASSED. The F12 pass bar — every F12 property present in every
+confirmation regen — is met. No adoption (Option B); the shipped spec got the same template by
+the hand edit at `485e4ce` + step-4 fix at `e4c1c7d`.
+
+**Confirmation-set carried findings (residuals and observations, not F12 failures):**
+1. **Row-set variance, now better characterized**: it is a CLASS of judgment-boundary subjects,
+   not one subject. A: topology folded, summary-scope extra (structural route). B: 13 rows, all
+   12 canon subjects present, summary-scoping extra (contradicted route). C: topology present,
+   augmentation folded, initialization-semantics extra (contradicted route). Summary-scoping has
+   now entered via three different routes across two passes — it flickers because the boundary
+   is genuinely debatable (the course contradicts itself on it and scoping changes read
+   semantics). Owner decision at ship: keep as residual, or admit it to the canonical subject
+   list. Core 24 properties stable in all three.
+2. **Id-alphabet drop is systematic on Opus-class** (0/3 pinned hex; A alphanumeric, B no
+   alphabet + a minLength:6 schema floor under a stated 8 chars [verified], C length-only),
+   while both Fable-class shakedown regens pinned hex — the first clean cross-model pinning gap.
+   Candidate guide finding for #18: identifier formats (alphabet included) named explicitly as
+   Pass-A working parameters. Not fixed this pass — fix and test travel together.
+3. Minor: B's P11 partial (question-never-summarized holds by construction but is never stated;
+   its context contract carries the question as a schema sibling of segments); B's S3 edge on
+   D13's global-pool alternative (outgrown-baseline reading — the a7de8ef litmus boundary again).
+4. Recurring builder friction (both probes/builders): §5 fixture literal `fixtures/llm-stubs.py`
+   is unimportable — candidate guide finding: fixture module names must be importable identifiers.
+
+## PAUSED — resume checkpoint (2026-09-08) [RESUMED and completed same day — kept for the record]
 
 Owner paused the pass mid-confirmation. State: guide + spec edits shipped locally through
 `e4c1c7d`; round 1 scored; both gate probes PASSED. **Pending:** confirmation regens B and C
@@ -98,6 +126,9 @@ note, the two new candidate findings — importable fixture filenames; probe-met
 |---|---|---|---|
 | A | bbe7189 | Opus-class | 24/26; **T1/T2/T3/L1/P2 all PRESENT [scorer + orchestrator grep, verified]** — first-try template conformance on the cheaper model. P1 PARTIAL (residual, below). P7 PRESENT with flag: summary ids 8-char alphanumeric, not hex — watch in confirmation. Scorer caught a **template defect (ours, not the regen's)**: step 4 still said "the step-2 as-is answer" — the rename missed one back-reference; regen-A copied the guide faithfully, blemish included |
 
+| B | e4c1c7d | Opus-class | **23 PRESENT / 3 PARTIAL / 0 ABSENT [full scorer + 6-verdict orchestrator spot-audit, verified]** — T1/T2/T3/L1/P2 all present incl. step-4 fix; 13 rows (all 12 canon subjects + D13 summary-scoping via contradicted route); P7 id alphabet unpinned + minLength:6 floor; P11 sub-item (question guarantee structural, unstated) |
+| C | e4c1c7d | Opus-class | **Targeted greps [verified]: T1/T2/T3/L1, step-4 fix, N9 pin, topology row (D9, reduced-set alternative) all present** — 12 rows (augmentation folded; initialization-semantics extra via contradicted route); id length-only, no alphabet |
+
 **Round-1 fix:** guide step 4 "as-is answer" → "baseline answer" (+ same fix in the course
 spec's hand-edited §0). Not a regen leak — a template inconsistency introduced by the pass
 itself and caught by template-conformance scoring, which is the property type working.

From 129a65f19b53e30e9eb2bf50bf72c3a722475521 Mon Sep 17 00:00:00 2001
From: Carr1005 <carr@deeplearning.ai>
Date: Tue, 8 Sep 2026 10:54:37 -0700
Subject: [PATCH 7/7] =?UTF-8?q?Matrix:=20correct=20summary-scoping=20route?=
 =?UTF-8?q?=20count=20(two,=20this=20pass);=20record=20owner=20decision=20?=
 =?UTF-8?q?=E2=80=94=20admitted=20to=20canon,=20implementation=20queued?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 docs/research/guide-gate-semantics-matrix.md | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/docs/research/guide-gate-semantics-matrix.md b/docs/research/guide-gate-semantics-matrix.md
index bdefe9b..b5c25cb 100644
--- a/docs/research/guide-gate-semantics-matrix.md
+++ b/docs/research/guide-gate-semantics-matrix.md
@@ -90,11 +90,20 @@ the hand edit at `485e4ce` + step-4 fix at `e4c1c7d`.
 1. **Row-set variance, now better characterized**: it is a CLASS of judgment-boundary subjects,
    not one subject. A: topology folded, summary-scope extra (structural route). B: 13 rows, all
    12 canon subjects present, summary-scoping extra (contradicted route). C: topology present,
-   augmentation folded, initialization-semantics extra (contradicted route). Summary-scoping has
-   now entered via three different routes across two passes — it flickers because the boundary
-   is genuinely debatable (the course contradicts itself on it and scoping changes read
-   semantics). Owner decision at ship: keep as residual, or admit it to the canonical subject
-   list. Core 24 properties stable in all three.
+   augmentation folded, initialization-semantics extra (contradicted route). Summary-scoping entered
+   via two different routes within this pass (A: design-structural; B: contradicted) — it
+   flickers because the boundary is genuinely debatable (the course contradicts itself on it
+   and scoping changes read semantics). Core 24 properties stable in all three.
+   **OWNER DECISION (at ship): summary-scoping is ADMITTED TO THE CANON** — "a reasonable
+   different design is a Ledger decision": both sides are course-demonstrated working code,
+   never warned against (the cross-thread-leak indictment was regen-B's own extrapolation,
+   not course text), and the right answer depends on learner context (multi-context isolation
+   vs single-user recall) — the exact profile of a Ledger row, with the risk carried by the
+   Trade-off cell as the Ledger design intends. Implementation split (fix and test travel
+   together): the spec's summary-scoping row rides the owner's upcoming Loop-A revisions
+   batch; the guide example-sentence and the P1→13 canon update ride the next promotion pass
+   with its validation round. P1 stays at 12 subjects until then, avoiding a spec-vs-canon
+   mismatch window.
 2. **Id-alphabet drop is systematic on Opus-class** (0/3 pinned hex; A alphanumeric, B no
    alphabet + a minLength:6 schema floor under a stated 8 chars [verified], C length-only),
    while both Fable-class shakedown regens pinned hex — the first clean cross-model pinning gap.