Your first session

A working loop has three observable outcomes: a problem appears, its resolution is recorded, and a later session retrieves it. Start after the quickstart, using a small real issue in a project you can edit.

1. Check the workspace

errata status
errata privacy

Confirm the workspace, running daemon, and intended consent settings. Start a fresh agent session so it loads the integration. Ask it to read .errata/context.md when present.

2. Have the agent state the problem

The reliable conversation capture path uses inline tags in the assistant's own prose. Tool events and diagnostics provide context; a failing command followed by a passing command is not by itself proof that a problem and fix were linked.

An agent investigating a real empty-input bug might write:

[!Empty input crashes the parser @ src/parser.ts:42]

Use the actual issue and file. Do not manufacture a failure to populate the graph. Tags pasted only into a user message or fenced code block are not the same as the agent reporting an observation.

3. Check capture before the fix

After the agent's next supported hook or turn boundary:

errata g problems
errata search "words from the actual problem"

Expected: an open problem with a recognizable description and node ID. Capture is asynchronous. If absent, check hook delivery and transcript compatibility before assuming recall is broken.

4. Fix, verify, and record

Have the agent make the change and run the relevant check. For a problem shown in context, cite its real handle:

The parser returns an empty result; the empty-input test passes. (fix:[shown-handle])

For a problem the agent just stated, a descriptive fix tag is supported:

(fix: return an empty result before reading the first token)

Replace placeholders. State the verification result beside the fix, and claim resolution only when it worked.

errata g problems
errata search "words from the actual problem"
errata report

Expected: the resolved count increases and search still finds the matching problem. g problems lists open problems by default, so the resolved entry can disappear from that list. The local MCP errata.search result includes the problem's state; the CLI search summary does not. Inspect the returned ID and its causal neighborhood separately; a resolved state alone does not prove a complete cause-and-fix chain exists.

report writes a static HTML snapshot and prints the path; open that file yourself. It is not a continuously updating dashboard.

5. Retrieve it in a new session

Start another session in the same project, read the current context, and query the actual problem:

errata search "words from the actual problem"
errata burst "words from the actual problem" --local

Use a returned node ID for an exact lookup if text selects a different seed. Context is a budgeted selection; it need not display every lesson automatically. Explicit retrieval is the stronger check.

A useful lesson includes the symptom, cause when known, fix, and verification evidence. Check that it fits the current code.

6. Verify sharing separately

Local capture says nothing about cloud upload. Review errata whoami and consent, then run errata sync now when you want sharing.

Read each result: consent-off is an intentional skip, not an upload. A zero exit code does not prove any nodes reached the cloud. See Troubleshooting.