From e2109e4478d9531603584f44e8f9e6d826216398 Mon Sep 17 00:00:00 2001 From: Carr1005 Date: Tue, 28 Jul 2026 23:09:09 +0800 Subject: [PATCH] Turn D6 into a scope-boundary row in the variant spec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Mirrors the same fix applied to the canonical spec.md. D6 asked "anything explicitly unwanted?" without ever showing the learner what was already excluded, held a single Options entry (so it could not be asked through AskUserQuestion's 2-4 option requirement), and defaulted to a pointer at a section the gate never renders. The row now carries the §1 list into the question and lets the learner name what they want back, rather than the spec guessing for them. Routing differs from the canonical row because this variant's §1 was rewritten: it has no "Oracle-specific operations" bullet (the store admin bullet is now store-agnostic) and no "integration into an existing codebase" bullet (replaced by the retrofit-scope bullet, since D1 here retrofits an existing chat app). The handling rules follow this file's §1, not the canonical one. Co-Authored-By: Claude Opus 5 (1M context) --- .../spec.coding-agent-lab.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/courses/agent-memory-building-memory-aware-agents/spec.coding-agent-lab.md b/courses/agent-memory-building-memory-aware-agents/spec.coding-agent-lab.md index b97a989..f14a0c8 100644 --- a/courses/agent-memory-building-memory-aware-agents/spec.coding-agent-lab.md +++ b/courses/agent-memory-building-memory-aware-agents/spec.coding-agent-lab.md @@ -67,7 +67,7 @@ when you have reason to prefer another option. | D3 | learner | `[goal]` — what "working" means. | — | **Cross-session continuity**: the agent answers follow-ups without re-doing discovery, keeps context under budget via recoverable summarization, and can still recover the thread's first question after summarizing (the §5 oracle). | Continuity guarantee (default); latency/cost targets; retrieval-precision targets | Stricter retrieval goals push toward reranking/hybrid search — out of course scope (§1 Not Included). | learner | | D4 | learner | `[model/provider]` — the LLM behind reasoning, summarization, augmentation, extraction. | Must support **native (OpenAI-style) tool calling** and a system role; its context-window size must be known to the budget monitor (R6). | **OpenAI**: `gpt-5.6-luna` for the agent loop, `gpt-5.6-terra` for docstring augmentation and entity extraction — the two roles the course filled with `gpt-5-mini` and `gpt-5`. Read the key and any provider base URL **from the environment at runtime**, never from a committed file (§2). LLM-dependent ACs are tagged `scripted` or `live` so the offline oracle still runs (§5). The budget monitor (R6) needs one number for the loop model's context window: **256,000 tokens** — the course's configured value, carried forward; verify it for the model you pin and change it in its single config point (R15) if it differs. | OpenAI gpt-5.6-luna + gpt-5.6-terra (default); Anthropic claude-sonnet-5 + claude-sonnet-4-6 — capable, but reached through an Anthropic-shaped endpoint, so it needs that SDK and its tool-call message shape rather than the OpenAI-style calls §3 specifies; the course's gpt-5-mini + gpt-5 (course default); any other model meeting the invariant | Changing provider means re-checking the tool-call message shapes and the token budget in R6; prompts (summarization, extraction) may need re-tuning. | learner | | D5 | learner | `[environment]` — where it runs. | **All seven memory stores must survive process restarts** (memory is external to the model and persistent). | Local machine, Python 3.11+, single on-disk database file (realization: D14). First run needs network to download the embedding model; no Docker, no admin setup. | Local single file (default); any server environment | A shared/server environment adds connection management the course's local pattern doesn't cover. | learner | -| D6 | learner | `[out-of-scope]` — anything explicitly unwanted. | — | Nothing beyond §1 "Not Included". | Add exclusions freely | Exclusions only shrink scope; they never relax the D5/D7 invariants. | learner | +| D6 | learner | `[out-of-scope]` **Scope boundary** — what this build leaves out, and whether the learner wants any of it back. Present the §1 "Not Included" list inside the question itself, so the learner is choosing against something they can see; do not pre-select what they might restore. If they choose to amend, capture which items, then apply: additive and owned by no other row → restore it; named by the course but never built (semantic caching, scratchpads, reranking, graph retrieval, decay, fine-tuning) → buildable, but state that this spec supplies no parameters and no acceptance criteria for it; hybrid search and store-specific database administration → defer to D14, do not decide here; rebuilding or redesigning the app being retrofitted, and porting these mechanisms into a different application → unavailable in this build mode. | — | **Keep as-is** — every §1 exclusion stands; build the full §5 acceptance set (AC1–AC20). | Keep as-is (default; no "(course default)" applies — the course has no opinion on this dimension); bring something back — the learner names it | Anything restored is additive: it must not change behavior AC1–AC20 assert, and it ships with no acceptance criteria and no Context Pack guidance — the learner owns its verification. An exclusion the learner adds may shrink the build but never deletes another row's Invariant. Either amendment belongs in the §0 step-5 checklist. | learner | | D7 | design-argued | **Memory-core topology** — which memory types exist and their storage class. | Seven memory types, each with a dedicated store: **conversational + tool-log memory retrievable by exact key (thread) in chronological order; knowledge-base, workflow, toolbox, entity, and summary memory retrievable by semantic similarity.** | The course's seven stores: `CONVERSATIONAL_MEMORY` and `TOOL_LOG_MEMORY` as SQL-style tables; `SEMANTIC_MEMORY` (knowledge base), `WORKFLOW_MEMORY`, `TOOLBOX_MEMORY`, `ENTITY_MEMORY`, `SUMMARY_MEMORY` as vector stores — all fronted by one memory-manager abstraction (CTX-A, CTX-C1). | Seven-store split (course default); fewer stores (e.g. fold entity into KB); more (add semantic cache) | Lesson 3 argues the split: conversation needs *exact* retrieval by thread id, "not similarity search", while knowledge/workflow/toolbox/entity/summary need meaning-based lookup; collapsing stores loses the retrieval strategy matched to each type. | course | | D8 | design-structural | **Deterministic vs agent-triggered operation split** — which memory operations the harness runs every turn vs which the model may invoke. | Context-building reads (conversation, KB, workflow, entity, summary-index) and post-turn writes (conversation, workflow) run **deterministically every turn**; judgment operations (expand a summary, summarize-and-store, external search, entity writes) are **also exposed as model-invocable tools**. | The course's classification (CTX-C2): deterministic = the five preload reads + conversation/workflow writes + the >80% budget check; agent-triggered = `expand_summary`, `summarize_and_store`, external search, deep paper ingest; `read_toolbox` is both. *Note (course-contradicted, carried here):* the Lesson 3/L2-notebook classification table marks entity **writes** and `read_summary_context` agent-triggered, yet the Lesson 6 loop runs both deterministically (entity extraction after query and answer; summary-index read in every preload) — this spec follows the Lesson 6 working loop. | Course split (course default); fully agent-managed memory; fully hardcoded memory | Moving reads/writes to model discretion risks "forgot to save" gaps and the chicken-and-egg problem (CTX-B7); hardcoding judgment ops (e.g. always summarize) wastes tokens and clutters memory (CTX-C2). | course | | D9 | design-argued | **Partitioned context window + memory-aware system prompt** — how assembled memory is presented to the model. | The model input carries the question first, then **one labeled segment per memory type**, and the model instructions name each segment, its usage guidance, and a conflict-priority order (R16). | Markdown-heading partition in fixed order: `# Question`, then `## Conversation Memory`, `## Knowledge Base Memory`, `## Workflow Memory`, `## Entity Memory`, `## Summary Memory`, each segment self-describing ("what this memory is / how you should leverage it"). | Partitioned + self-describing (course default); one mixed context block; structured JSON context | Lesson 6 argues markdown headings let the model exploit its latent grasp of hierarchical structure, giving "structured, role-specific context instead of one mixed block"; a mixed block loses per-store semantics. | course |