[pegner-ag]

Plan 08b (tasks/f1-skeleton/task-08-reception/plan-08b.md, includes the plan commits of #54 with the owner's change to decision 7).

• Home page: one box with a project picker (remembered), the live conversation with the reception (Markdown replies, numbered options, buttons, a link to each task it started, reports), earlier conversations, the folded exact-task form, the inbox's lists.
• Conversation page /conversations/{id} (read only unless open on the web); the server's redaction notice links there.
• Memory /memory/{scope} and Operator preferences /memory/operator: add, edit, pin, done, forget.
• Server: GET /api/v1/projects (names only, within the cap) and POST /api/v1/memory/{scope} (web session only, secret scan, refused when personal data would raise the item above the author's cap; source = its own MEMORY_NOTED, so the event schema is unchanged).
• A tap always answers the newest decision, so older replies' taps are disabled.

Tests: full suite 1424 passed / 7 skipped; npm run check, npm test (35). Checked in headless Chromium against a scripted reception (send/Enter, options, Yes/Differently with a correction, Forget, project switch, memory add/refusal/pin, phone width). Reviewer: approve; its suggestions are applied.

Open point for the owner: operator memory is one scope per server, not per operator (as since 08a); fine for a single owner.

🤖 Generated with Claude Code

[claude]

Minor: any slug passes the scope check here. A slug that isn't in ooat.toml and has never been used (e.g. a typo in /memory/dcos) quietly falls back to internal through project_class and creates a new memory scope. That scope can hold a pinned item that steers later tasks. Consider accepting only the slugs that GET /projects would offer this operator, or operator. The class check itself is correct: note() raises the class for personal data, and require_within checks the raised class.

[claude]

Nit (performance): every home page load reads all TASK_SUBMITTED and CONVERSATION_MESSAGE events in the ledger, from every operator. That is fine for F1 with SQLite, but it grows with the ledger. If it becomes a hotspot, filter by actor in the query, or move this to a view (db-dev).

[claude]

Nit: "2000" copies memory.MAX_TEXT here and at line 91. If the server limit changes, the UI will drift from it without any error. A named constant (or a comment pointing at memory.MAX_TEXT) would make the link visible.

[claude]

Verdict: looks good. Only minor suggestions, posted inline.

Security invariants: hold

• POST /memory/{scope} is refused outside a web session. This matches the existing rule for editing and pinning (design 08 §8).
• Text that looks like a secret is refused, and the secret is not echoed back in the error (tested).
• If the text contains personal data, note() raises the item's class. The class is checked against the author's cap with require_within before anything is written, so no text file is left behind without its event (tested, DATA_CLASS_ABOVE_TOKEN).
• The ledger stays append-only. For an item written by hand, source is its own MEMORY_NOTED id. That is valid under body_memory_noted.source (an event_id), so the event schema does not change (ADR 0018).
• Markdown replies go through the existing markdown.js, which uses markdown-it with html: false and is the app's only innerHTML.
• GET /projects returns names only, no folder paths, and limits them to the reader's cap. Projects that are not in ooat.toml are shown only to the operator who used them (tested).
• No R3 path is touched. No secrets or real personal data in fixtures: the email in the test uses example.cz.

Suggestions (minor)

1. add_memory accepts any slug, so a typo creates a new internal scope that can hold a pinned item. Consider limiting it to the projects the picker would offer.
2. list_projects reads every event of those two types on every home page load. Fine for now; worth watching as the ledger grows.
3. maxlength="2000" in memory.js copies memory.MAX_TEXT by hand.

Docs: docs/description.md now describes the web app and the chat bridge as they are in this PR. The /pamet command it mentions already exists in bridge.py.

Open point for the owner: the operator memory is one scope per server, not one per operator, as the PR description says. That is fine for a single owner, but it needs a decision before multi-operator use.

I could not run pytest in this environment. The tests I read (test_api_conversations.py) cover the new endpoints: the web-only rule, secret scan, cap refusal, kind and scope validation, and project listing.