P1: Verify persistent personal instructions end-to-end for restricted Accounts, including compaction #155

Evidence and scope

Based on a private support handover dated 2026-10-02 and a follow-up report dated 2026-10-06. Customer identities, deployment coordinates, project paths, session identifiers, and raw attachments are deliberately omitted. Code references are pinned to current public master (3f90286), not the reporter's deployed build or uncommitted local changes. Production was not accessed or modified during this triage.

Reported requirement versus current master

Support reports an unresolved need for two distinct users to save general/persistent instructions and have them applied reliably. Their deployed workflow and exact failure were not audited in the handover; no specific root cause is established.

Current master already implements this feature. Investigate deployment parity, permissions, persistence, UI feedback, and effective model context instead of inventing a second instruction store or a shared global preference.

Existing implementation to use

• Instruction scope contract defines Host, shared Project, and private Personal scopes, next-turn application, 32,000-character limits, and Host > Project > Personal model guidance.
• Settings editor.
• Personal and Project routes resolve the Account from authentication.
• Host instruction resolution composes current Host, Project, and actor-specific Personal text for the Harness.
• Scope composition, Host tests, and isolation integration tests.

Diagnosis and acceptance

Use two approved fixture Accounts with different harmless marker preferences; do not copy real customer instructions into tests or logs.

• Verify the deployed code/settings support the existing scopes; record any version mismatch before calling this an implementation defect.
• Each Account can save, read, edit, and delete its own Personal instructions; another Account cannot read or modify them by supplying an ID in query/body.
• Save/read failures are visible and preserve drafts; no false success state.
• Restart/reconnect/Session switching retains instructions without cross-Account leakage.
• Inspect deterministic captured ModelRequest.systemPrompt (and a controlled integration flow) to verify the correct actor's text is injected on new and existing Sessions' next turns, including queued prompts.
• Manual and threshold compaction retain/re-resolve relevant instruction scopes for continuation, independently of incidental text in old history. Coordinate with P0: Restricted users cannot compact because internal handoff storage uses project file permissions #150 and P0: Compaction failure repeatedly blocks Sessions and is mislabeled as a model-provider error #151.
• Shared-Session execution uses the requesting actor, not the Session owner's private preferences; API keys do not inherit user preferences.
• Project edit permissions and concurrent saves remain isolated; empty/oversized text follows existing documented validation.
• Explain scope/priority/next-turn behavior clearly in en/de/es; do not silently change the existing contract.
• Instructions never grant filesystem, model, or tool permissions or bypass Host safety rules.

A production reproduction remains necessary before choosing a technical fix. Close as deployment verification if the existing implementation meets the contract, with redacted evidence rather than a speculative new feature claim.