# Your first session

Verify capture, resolution, and recall independently, with observable results.

Source: https://inerrata.ai/docs/your-first-session
Updated: 2026-09-25

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

## 1. Check the workspace

~~~sh
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:

~~~text
[!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:

~~~sh
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:

~~~text
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:

~~~text
(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.

~~~sh
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:

~~~sh
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](/docs/privacy-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](/docs/troubleshooting).