docs(topic-docs): out-of-repo storage convention for long-lived memory content

[kyle-sexton]

Deferred question Q12 from the work-folder-hierarchy Brief (PR #3552), graduated at effort end per the topic-docs tracker edge.

.work memory content is checkout-scoped and never committed, which fits ephemeral task work — but some content outlives a worktree (worktrees churn; cloud containers are reclaimed), and a convention for externalizing long-lived memory (machine-scoped store, ${CLAUDE_PLUGIN_DATA}-class location, or a configurable external root) was deliberately deferred rather than designed in the v3 wave. Decide whether such a convention is wanted, what qualifies for it, and how it composes with the knowledge library_dir seam and the visibility matrix.

Blocked by the v3 hierarchy landing (parent epic); design decision reserved for the user (arbiter: USER-RESERVED in the Brief).

[claude]

---

Generated by Claude Code

[claude]

This was generated by AI during triage.

Triage outcome: human-gated (user-reserved design decision, currently blocked)

This item routes to a human by its own terms, not by triage judgment. The body records the arbiter as reserved for the user in the originating Brief. A triage lane cannot default a decision whose arbiter is explicitly named.

Verification (2026-09-06). The provenance checks out. The originating pull request, which locked the work-folder-hierarchy Brief as the topic-docs contract, merged on 2026-09-01, and this item is its graduated deferred question, filed as the contract's tracker edge prescribes.

Blocked state. The named blocker is the hierarchy implementation landing under a parent epic. The merged pull request locked the Brief, not the implementation, so that merge does not clear it. This pass could not resolve the parent epic to an issue number, so no dependency edge was created; a future pass that identifies it should add the edge.

The problem is real and worth stating plainly: local memory content is checkout-scoped and never committed, which is correct for ephemeral task work. But worktrees churn and cloud containers get reclaimed, so content that outlives a worktree is currently stored somewhere it will be destroyed. That is a durability gap, not a preference.

The decision, restated so it is not re-derived:

1. Is an out-of-repo storage convention wanted at all, or is the checkout-scoped rule absolute and long-lived content simply belongs somewhere already durable?
2. If wanted, what qualifies. This is the load-bearing sub-question: a rule that lets anything be externalized recreates an unmanaged store, and the value of the checkout-scoped rule is that it makes memory disposable by default.
3. Where: a machine-scoped store, a plugin-data-class location, or a configurable external root. These differ in whether the content follows the machine, the plugin, or the operator.
4. How it composes with the knowledge plugin's library-directory seam and the visibility matrix, both of which already govern content location and would otherwise offer a second answer to the same question.

Not blocked on information. Nothing further is needed from the filer; this needs the reserved arbiter and its blocker cleared.

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during attend-queue.

Closing (operator decision, 2026-09-27): no out-of-repo memory convention now. Revisit after a real loss when a worktree or container is reclaimed.