docs: clarify personal-agent profile naming
This commit is contained in:
Svrnty
+32
-30
@@ -1,44 +1,45 @@
|
||||
---
|
||||
name: 2026-06-14-steev-personal-context-runtime-prd
|
||||
name: 2026-06-14-personal-agent-context-runtime-prd
|
||||
status: active
|
||||
triage: ready-for-agent
|
||||
owner: jp
|
||||
source: user-request-2026-06-14-steev-personal-context-runtime
|
||||
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 Steev the governed personal context runtime over iMessage, Proton, rclone, and future host-control capabilities.
|
||||
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
|
||||
---
|
||||
|
||||
# Steev Personal Context Runtime PRD
|
||||
# Personal-Agent Context Runtime PRD
|
||||
|
||||
## Problem Statement
|
||||
|
||||
JP wants Steev, his personal-agent profile, to know him through the live
|
||||
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 old work for active
|
||||
authority, build duplicate connectors, route private personal context toward
|
||||
the wrong memory domain, or claim runtime readiness from partial proofs. Steev
|
||||
needs one clean profile contract that says which personal surfaces are active,
|
||||
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 Steev a governed personal context runtime profile. The profile declares
|
||||
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
|
||||
Steev owns the profile-level decision that those packages belong to JP's
|
||||
personal-agent and must route personal context only through governed personal
|
||||
`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:
|
||||
@@ -53,21 +54,21 @@ The first target state is read-first and proof-backed:
|
||||
|
||||
## User Stories
|
||||
|
||||
1. As JP, I want Steev to understand my recent iMessage exchanges, so that he can answer with real personal context.
|
||||
2. As JP, I want Steev 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 in Steev.
|
||||
4. As JP, I want Steev to read Proton Mail, so that my personal-agent knows what people are asking me.
|
||||
5. As JP, I want Steev to draft Proton replies without sending them, so that I keep final control of outbound mail.
|
||||
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 Steev to read Proton Calendar, so that it knows my time commitments.
|
||||
8. As JP, I want Steev to propose calendar changes before writing them, so that scheduling remains controlled.
|
||||
9. As JP, I want Steev to read Proton Contacts, so that it can identify people across channels.
|
||||
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 Steev to read Proton Drive through rclone, so that it can find personal context when I ask.
|
||||
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 Steev to use Keyvault references only, so that this project does not become a credential migration.
|
||||
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.
|
||||
@@ -82,7 +83,7 @@ The first target state is read-first and proof-backed:
|
||||
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 Steev's manifest and disclosure to match live capability exposure, so that runtime drift is caught.
|
||||
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.
|
||||
@@ -92,8 +93,9 @@ The first target state is read-first and proof-backed:
|
||||
|
||||
## Implementation Decisions
|
||||
|
||||
- Steev owns the profile-level personal context runtime contract; individual integrations remain child capability packages.
|
||||
- BlueBubbles owns the iMessage capability package. Steev consumes the package as `imessage.read` and does not implement a second connector.
|
||||
- `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.
|
||||
@@ -110,7 +112,7 @@ The first target state is read-first and proof-backed:
|
||||
|
||||
## Testing Decisions
|
||||
|
||||
- The highest profile seam is Steev's validator plus manifest/disclosure consistency.
|
||||
- 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`.
|
||||
@@ -118,7 +120,7 @@ The first target state is read-first and proof-backed:
|
||||
- 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 Steev child validator passing.
|
||||
- Every completed slice must leave the current distribution validator passing.
|
||||
|
||||
## Out of Scope
|
||||
|
||||
@@ -131,13 +133,13 @@ The first target state is read-first and proof-backed:
|
||||
- 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 Steev planning route.
|
||||
- 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 Steev's profile contract. BlueBubbles remains the concrete
|
||||
experiments to the `personal-agent` profile contract. BlueBubbles remains the concrete
|
||||
iMessage package. Proton/rclone becomes the next standardized capability
|
||||
package. Steev becomes the governed personal-agent profile that declares which
|
||||
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.
|
||||
Reference in New Issue
Block a user