steev/docs/prd/2026-06-14-personal-agent-context-runtime-prd.md

---
name: 2026-06-14-personal-agent-context-runtime-prd
status: active
triage: ready-for-agent
owner: jp
source: user-request-2026-06-14-personal-agent-context-runtime
created: 2026-06-14
last_reviewed: 2026-06-14
core_promotion_status: not-promoted
description: PRD for making the personal-agent profile the governed personal context runtime over iMessage, Proton, rclone, and future host-control capabilities.
artifact_type: prd
---

# Personal-Agent Context Runtime PRD

## Problem Statement

JP wants the `personal-agent` profile, displayed to users as Steev, to know him through the live
communication and personal-data surfaces that already shape his day: iMessage,
Proton Mail, Calendar, Contacts, Proton Drive through rclone, and later the Mac
Mini browser host. Today those surfaces exist in different states across
profile docs, BlueBubbles child work, Proton skills, older Cortex repositories,
Docker services, systemd units, Hermes adapters, and Secondbrain/curator lanes.

The risk is context confusion. Future agents can mistake the Steev display name
or old work for active profile authority, build duplicate connectors, route
private personal context toward the wrong memory domain, or claim runtime
readiness from partial proofs. The `personal-agent` profile needs one clean
contract that says which personal surfaces are active,
which capability package owns each surface, which mutations are forbidden,
which durable memory route is allowed, and which old artifacts are archived,
superseded, or legacy reference only.

## Solution

Make `personal-agent` a governed personal context runtime profile. The profile declares
the personal context surfaces it may observe, the capability packages that
provide those surfaces, the exact memory routing policy, the mutation policy,
and the runtime readiness gates. BlueBubbles/iMessage, Proton/rclone, and
future browser/Webwright host control stay in separate capability packages, but
`personal-agent` owns the profile-level decision that those packages belong to JP's
personal-agent runtime and must route personal context only through governed personal
memory paths.

The first target state is read-first and proof-backed:

- iMessage is `imessage.read` only.
- Proton exposes read, draft, propose, and confirmation-gated write surfaces.
- Proton Drive through rclone starts as `drive.read`.
- Durable memory proposals target only personal Secondbrain storage.
- `orgbrain` is forbidden for message, mail, contact, calendar, and drive-derived personal context.
- Core stores no raw personal content, endpoint payloads, credentials, or secret values.
- Old work is classified so graph context has one canonical pickup path.

## User Stories

1. As JP, I want `personal-agent` to understand my recent iMessage exchanges, so that he can answer with real personal context.
2. As JP, I want `personal-agent` to read iMessages without sending, so that personal-agent context does not mutate my Messages state.
3. As JP, I want BlueBubbles to be the iMessage capability package, so that iMessage runtime work is not duplicated inside the profile distribution.
4. As JP, I want `personal-agent` to read Proton Mail, so that my personal-agent knows what people are asking me.
5. As JP, I want `personal-agent` to draft Proton replies without sending them, so that I keep final control of outbound mail.
6. As JP, I want Proton sends to require explicit confirmation, so that no agent sends mail silently.
7. As JP, I want `personal-agent` to read Proton Calendar, so that it knows my time commitments.
8. As JP, I want `personal-agent` to propose calendar changes before writing them, so that scheduling remains controlled.
9. As JP, I want `personal-agent` to read Proton Contacts, so that it can identify people across channels.
10. As JP, I want contact writes to require explicit confirmation, so that my address book is not changed silently.
11. As JP, I want `personal-agent` to read Proton Drive through rclone, so that it can find personal context when I ask.
12. As JP, I want Drive writes to be confirmation-gated, so that personal files are not changed silently.
13. As JP, I want all personal context routed to personal Secondbrain storage, so that my private life stays personal.
14. As JP, I want `orgbrain` forbidden for this data, so that personal messages and mail never become organization memory.
15. As JP, I want `personal-agent` to use Keyvault references only, so that this project does not become a credential migration.
16. As JP, I want Core to store only redacted proofs, so that governance can be reviewed without exposing personal content.
17. As JP, I want each capability to report health without leaking payloads, so that runtime readiness is observable and private.
18. As JP, I want the Mac Mini BlueBubbles runtime to stay always-on, so that iMessage context is available continuously.
19. As JP, I want Proton services to have one canonical runtime path, so that Docker, systemd, and MCP do not fight each other.
20. As JP, I want rclone to use an explicit governed config path, so that Drive access is repeatable and not ambient.
21. As JP, I want browser/Webwright Mac control separated from messaging, so that full computer authority is approved deliberately.
22. As JP, I want desktop app integration to wait for the adapter lane, so that UI work uses the right service boundary.
23. As JP, I want conductor and curator to become the standard service path, so that capabilities are centralized cleanly.
24. As JP, I want every old planning artifact classified, so that future graph context has no ambiguous authority.
25. As JP, I want superseded work marked visibly, so that agents do not revive stale plans.
26. As JP, I want active capability packages named explicitly, so that agents know where to continue work.
27. As JP, I want legacy repositories treated as reference material, so that useful code is preserved without becoming authority.
28. As JP, I want runtime readiness separated from Seed readiness, so that package claims are not inflated.
29. As JP, I want final completion to require profile, capability, runtime, memory, and graph hygiene acceptance, so that "done" has one meaning.
30. As a profile maintainer, I want the personal-agent manifest and disclosure to match live capability exposure, so that runtime drift is caught.
31. As a capability maintainer, I want each surface to declare allowed and forbidden effects, so that test coverage follows real risk.
32. As a Secondbrain maintainer, I want proposal-only intake before durable apply, so that memory writes remain governed.
33. As a conductor operator, I want service identity and health shapes per capability, so that the central service lane can adopt them.
34. As a curator operator, I want redacted apply envelopes, so that personal memory can be reviewed without raw payload sprawl.
35. As a desktop adapter operator, I want one profile capability contract, so that the desktop app can display personal-agent readiness without guessing.
36. As a future agent, I want a sandcastle pickup map, so that I continue vertically instead of re-planning horizontally.

## Implementation Decisions

- `personal-agent` owns the profile-level personal context runtime contract; individual integrations remain child capability packages.
- Steev is the user-facing display name and current distribution/repo alias for `personal-agent`; it is not a separate product authority.
- BlueBubbles owns the iMessage capability package. `personal-agent` consumes the package as `imessage.read` and does not implement a second connector.
- Proton/rclone must become a standardized capability package with declared surfaces for Mail, Calendar, Contacts, and Drive.
- The personal-agent memory target is personal Secondbrain storage only. `orgbrain` is a hard-denied target for this work.
- Runtime claims require redacted live proof and a local validator. Partial service availability must be named per surface.
- Mutations use surface names that encode consent: read, draft, propose, send-with-confirmation, and write-with-confirmation.
- Message sends, mail sends, mark-read/read receipts, deletes, contact mutation, calendar mutation, and file mutation are forbidden unless the surface explicitly requires confirmation and JP confirms.
- Core promotion is out of scope for the child route. Core may receive only governed promotion packets and redacted evidence.
- Seed readiness is out of scope until the Seed lane accepts a package.
- Desktop app integration must wait for the adapter lane to settle.
- Conductor and curator are the desired service and apply path, but this PRD does not mutate those workspaces.
- Browser/Webwright Mac Mini host control is a separate runtime route because it grants broader computer authority than read-only communications.
- Old work must be classified in a supersession register before final readiness claims.
- Hindsight compliance means every major decision has a durable pickup artifact, a supersession state, and a one-line reason.
- Indie-dev compliance means vertical slices stay small, demoable, and useful without adding process that does not reduce confusion or risk.

## Testing Decisions

- The highest profile seam is the personal-agent distribution validator plus manifest/disclosure consistency.
- The highest iMessage seam is the BlueBubbles read-only runtime package and its redacted watchdog proof.
- The highest Proton seam is a redacted health check per surface: Mail, Calendar, Contacts, and Drive.
- The highest memory seam is a proposal envelope that targets personal Secondbrain storage and rejects `orgbrain`.
- The highest graph-hygiene seam is the supersession register plus graph context showing one canonical pickup path.
- The highest runtime seam is always-on supervisor posture with redacted proof, not raw payload capture.
- The highest desktop seam is a contract handoff, not UI wiring, until the adapter lane releases.
- Tests should assert external behavior: allowed reads work, denied mutations fail before transport, confirmation-gated writes cannot run silently, personal memory proposals do not become durable writes, and proof files contain no raw personal data or secrets.
- Every completed slice must leave the current distribution validator passing.

## Out of Scope

- Sending iMessages.
- Sending mail without explicit confirmation.
- Deleting messages, mail, calendar events, contacts, or files.
- Marking messages or mail read unless a later approved surface grants it.
- Downloading attachments unless separately approved.
- Reading or exporting password-manager contents.
- Granting browser/Webwright full computer control through this PRD.
- Writing durable Secondbrain memory directly from capability packages.
- Routing any personal context to `orgbrain`.
- Mutating Core, Seed, conductor, curator, desktop adapter, BlueBubbles, Proton, or Secondbrain workspaces from this personal-agent planning route.

## Further Notes

This PRD intentionally moves the center of gravity from individual connector
experiments to the `personal-agent` profile contract. BlueBubbles remains the concrete
iMessage package. Proton/rclone becomes the next standardized capability
package. The current Steev-named distribution becomes the governed `personal-agent` package that declares which
capabilities are allowed, how they route memory, and which old work is no
longer authoritative.