Capstone Charter: Problem, User, and Bounded Scope
Agent-Assisted Engineering Check
Prerequisites
Days 82-84 scientific agent evaluation; the bounded agent Learning Project at projects/agent_learning and its four-language guides.
Learning Objective
Author a one-page capstone charter that binds a concrete problem, a named user, an explicit scope boundary, and non-goals, reusing the previously verified bounded agent rather than hiding a new unbounded system inside the capstone.
Instructions
1. Re-read projects/agent_learning/README.md and agent.py; list the registered bounded tools (list_notes, read_note, write_report) and the fixture task summarize-notes.
2. Write the problem statement: the capstone extends the verified notes-to-report agent with exactly one new bounded tool (for example count_words or list_deadlines) and one additional fixed task, still scored by the existing independent scorer.
3. Name the user (a learner assembling study notes into a report) and the usage context (a local, offline-first disposable fixture workspace).
4. Draw the scope line. IN: the deterministic adapter, registered bounded tools, fixed fixtures, step/retry budgets. OUT: open-web browsing, arbitrary shell execution, unbounded retries, production autonomy.
5. Declare non-goals: no live-model claims until the ticket-23 authorization gate is approved; no new agent framework; no hidden network calls.
6. Save the draft as capstone_charter.md.
Practice & Prediction Log
Draft capstone_charter.md with sections Problem, User, In-Scope, Out-of-Scope, and Non-Goals. Then classify three feature requests as in-scope or out-of-scope: (a) 'read a third note from the fixture', (b) 'let the agent pip-install any package it wants', (c) 'add a bounded word-count tool'.
Ask whether the feature crosses a resource or permission boundary already enforced by agent.py; (a) and (c) stay inside the fixture, while (b) grants unbounded execution.
Reference ruling: (a) in-scope (fixture change only); (b) out-of-scope (arbitrary package installs are unbounded execution); (c) in-scope (one bounded deterministic tool). A charter is acceptable only when every in-scope item maps to an existing bound - a registered tool, a fixture, or a budget - and the non-goals name at least three excluded capabilities.
Produce a charter whose every in-scope item maps to a stated bound and whose non-goals explicitly exclude at least three capabilities (e.g., web browsing, arbitrary code execution, unbounded retries).
Authoritative Source Resources & Provenance
ReAct: Synergizing Reasoning and Acting in Language Models
Relevant Section / Range: Sections 2-4: interleaved reasoning/action protocol; Figure 1 trace format
Verified Version & Date: ICLR 2023 / arXiv:2210.03629v3 (Verified: 2026-10-30)
Primary literature for interleaving explicit reasoning steps with bounded tool actions; anchors the capstone's requirement that every step produces an inspectable observation inside a budgeted loop.
Language-model prompting, tool-call loops, and basic action/observation traces.
The curriculum restates the action/observation loop and reimplements a deterministic three-tool agent locally; no paper text is imported.
Compared Candidate Sources & Selection Analysis (2)
Pure reasoning traces without tool actions; ReAct adds the observable action/observation protocol that the capstone harness enforces.
Embodied closed-loop planning for robotics; ReAct's text-domain tool protocol maps directly onto the capstone's bounded tools.
Model Cards for Model Reporting
Relevant Section / Range: Section 4 Model Card Sections (4.1-4.9)
Verified Version & Date: FAT* 2019 / arXiv:1810.03993v3 (Verified: 2026-10-30)
Standard framework for disclosing a model's intended use, evaluation conditions, and limitations; supplies the capstone's model-choice and provenance documentation pattern.
Basic model evaluation vocabulary: dataset, metric, intended use.
The curriculum provides a local model-decision table template covering intended use, evaluation data, and caveats.
Compared Candidate Sources & Selection Analysis (2)
Dataset-side documentation rather than model-side; used alongside Model Cards in the provenance table rather than as a replacement.
Vendor-specific safety disclosure; Model Cards provide the general reusable schema.