RFC: writable global sources (content-only)

[ivklgn]

Problem

Global sources are read-only everywhere outside the MCP read tools. Relaxing this to allow content writes (relations would stay forbidden) is a substantial change with open questions — write-addressing scheme, provenance marker, path hardening, atomic writes — and it touches several accepted rules/decisions.

Expected result

An RFC that resolves the open questions and includes a security review, ending in a recorded decision to either amend the read-only rule or reaffirm it.

Impact

Ensures a risky change to the globals trust model is made deliberately, with the path-traversal and provenance implications reviewed up front.

Scope

• Resolve the open design questions.
• Security-review the write-addressing and path-traversal surface.
• Record the decision (or rejection); update the idea's status.

Files: a new RFC/decision doc under .archcore/

Acceptance: the design is settled and the read-only rule is either amended or reaffirmed.

Status: design/RFC + security review only.

[ivklgn]

Re-checked against v0.7.0: still open. .archcore/globals/writable-global-sources.idea.md is draft and keeps its Open questions section.

One new input for the RFC. The read-only model now reaches further than it did when this issue was written: the hook write guard (cmd/hook_write_guard.go) denies a direct editor write to a global document, including one mounted from outside the store, through the same predicate the MCP write tools use (docs.GuardWritablePath, docs.IsExternalGlobalDocument).

The idea's founding premise — that read-only is a router rather than a guard, because the user can always open the global as its own primary — still holds. But the guarded surface is larger, so the RFC now has to say what happens to the write guard, not only to the MCP write tools.