Memory And Review
How trading memory, review evidence, and contributor notes stay separate and inspectable.
What memory means to an operator
For an operator, memory means the evidence that helps explain a decision:
- prior runs that were retrieved as similar context
- market context packs and data-quality flags
- specialist and manager outputs
- broker/account state used during review
- persisted traces, trade context, and review snapshots
- source attribution, freshness, and missing-evidence notes
Memory is inspection support. It is not hidden permission to trade, and it should not silently mutate broker, risk, or runtime policy.
Review evidence
When a result looks suspicious, review evidence in this order:
- provider and market artifacts, including
as_of, freshness, completeness, and fallback state - runtime state, supervisor state, and logs
- broker/account status, execution outcome, and rejection reason
- specialist and manager outputs
- persisted review snapshots and UI behavior
Do not jump from "the answer feels wrong" straight to "the prompt must be rewritten". First verify what data, state, and evidence the system actually saw.
Trading memory versus contributor notes
Agentic Trader also has contributor-facing repo memory. That includes:
.ai/current-state.instructions.md.ai/tasks.instructions.md.ai/decisions.instructions.md.ai/qa/*- docs pages that explain current working assumptions
Those files help maintainers keep the project aligned. They are not the same as the product's trading memory, similar-run retrieval, or review evidence shown to an operator.
When contributor notes should change
Update .ai notes when a change affects:
- runtime behavior
- product direction
- developer workflow
- frontend or docs architecture
- QA expectations
- safety boundaries
Docs responsibility
This docs site is part of the contributor-maintained knowledge base, but it should be written for operators first. Whenever a durable decision changes, the right follow-up is usually:
- update the implementation
- update the relevant docs page
- update
.ai/current-state.instructions.md - update
.ai/decisions.instructions.md - update
.ai/tasks.instructions.mdif work remains
The key wording rule: describe product memory as decision/review evidence, and
describe .ai files as contributor notes.
Feedback flow in plain language
The GitHub Pages docs build cannot write to the repository filesystem. Its feedback widget stores a short browser-local draft and prepares a prefilled GitHub issue link for manual submission.
If a future Node-hosted docs instance re-enables server-side feedback, it should keep local auditability explicit and avoid pretending that external forwarding succeeded when it did not.