Reassess first-party Space extension ownership after Phase 5

[ultmaster]

Context

Phase 4.6 introduced SpaceHandle.extension(namespace) as a connection point for owner-managed, per-Space stores. Storage owns namespace isolation and lifecycle, while the owning module owns the schema, operations, concurrency, and backend-specific implementation.

The first two production consumers are:

• Memory-worker bookkeeping in huabu.memory (counter, lastAnalyzedAt, and lastSeenThreadCursor). This is only the worker's operational state; the actual Space memory document is already stored through the space-memory blob scope.
• Assembled-prompt debug logs in huabu.prompt.log.

This keeps the storage port clean: it does not need feature-specific members or a lowest-common-denominator key/value API. It also gives both consumers per-Space placement, prevents writes for an absent Space, and removes their data with the Space.

Reason to revisit

The current design deliberately makes each extension owner responsible for every backend it supports. That tradeoff is not observable while Disk is the only implemented structured backend:

• The memory trigger currently implements its store directly as state.json under the Disk substrate. Memory is a first-party/core product feature even though this particular state is private, best-effort bookkeeping.
• Prompt debugging is clearly diagnostic rather than canonical product state, but it is worth checking whether a per-Space extension remains the right abstraction or whether it should use a general diagnostic logging sink.
• The substrate is intentionally unfenced. Resolving it checks Space existence, but owner writes are outside the structured mutation/deletion fence.

Phase 5 adds SQLite and therefore provides the first concrete test of whether extension ownership is the right boundary or merely moves portability work into first-party feature modules.

Re-evaluate after Phase 5

Once the Phase 5 adapter is complete, review the following:

• Should memory-worker bookkeeping remain an extension-owned store?
• If memory must work for every selectable storage profile, where is that requirement enforced and who owns its backend implementations?
• Should agent/memory introduce its own typed MemoryTriggerRepository, with implementations constructed over SpaceSubstrate, rather than accessing the Disk directory directly?
• Should prompt debug logs remain a Space extension, become a diagnostic logging sink, or be explicitly unavailable on some profiles?
• Do first-party extensions need an explicit capability/fallback policy for unsupported backend kinds?
• Has Phase 5 exposed any lifecycle, deletion-race, migration, or testing gaps in the extension contract?

This issue is for recording the design question only. No Phase 4.6 change is requested now; the decision should be made using the Phase 5 implementation experience.

— posted by Codex (via the issue-tracker skill)