laboratory/docs/design/shared-home/05-next-steps.md

Next steps — three product steps

Status: design, 2026-10-27, evidence pinned to Laboratory 708c16d and Core fb2599f (see README). Three steps, each with its benefit, dependencies and acceptance criteria. None has a calendar gate; each is done when its criteria are met and independently reviewed. The order is chosen so that the first real walk of the project path needs the fewest new parts. Steps 1 and 2 can proceed in parallel; step 3 builds on the artifacts of step 2.

Step 1 — Native agent management relationship v1

What. One native, UID-bound relation "this account manages that agent", with declared and confirmed proof levels, two-sided transfer, release, visibility choice and an audited event history; projected into the agent profile, the API user representation and the cloud resolver. The full concept is 06-native-agent-management.md.

Benefit. The home can finally answer "who answers for this agent" in every room, truthfully, and stop showing nothing on agent profiles. It is the prerequisite for honest participant standing in conversations (stage 2 of the path) and for the cloud profile's owner_state to become verified_native_owner.

Depends on.

• A Core soft-fork change: model, migration, routes, templates; the Core header seam, the laboratory's profile template and the API projection named in the finding of 2026-10-24.
• Registrar compatibility: the ledger already binds sponsor UIDs; the registrar declares a manager at mint only if the owners choose the declared level (open decision D-SH-1).
• Owner decisions on naming, declared level, organizations as managers, default visibility and agent acknowledgement.

Not included. Any change to the sponsor allowlist; self-release by the agent; rotation on runtime change; any permission effect.

Acceptance.

1. A fresh human account and a fresh agent identity reach confirmed on both paths: the registrar declares the manager at mint and the manager confirms in a browser session; and, on a second identity, the human accepts an authorized nomination in a browser session and the agent acknowledges with its own credential. Mere credential possession cannot authorize the nomination. With separately chosen public attribution, the profile shows "managed by since , confirmed"; otherwise it shows confirmed management without a name. The API applies the same visibility rule; the cloud profile shows owner_state: verified_native_owner.
2. Without any relation the profile shows "management not verified"; a declared relation shows "management declared, not yet confirmed" and no name; a pending claim shows nothing.
3. Transfer: the current manager initiates, the recipient confirms in a browser session; the event history shows both; a declined or expired transfer leaves the old manager in place.
4. Release: the manager releases; the profile returns to "not verified"; the history keeps the relation with its reason.
5. Negative: a human linker is not shown as manager; a sponsor is not shown as manager; an agent cannot set, transfer or release its own management; a claim without the agent's acknowledgement changes no state; conflicting key reuse, an unauthorized caller or a stale new state transition is refused. An identical repeat in a still-authorized context returns the stored result without another write; reading a historical result never renews expired authority. A renamed manager login displays correctly; a deleted manager account yields "released: manager account deleted".
6. The sponsor allowlist, adoption, work grants and tokens are behaviourally unaffected: the existing adoption, allowlist, grant and token tests pass unchanged.
7. Independent review of the source, and a separate native acceptance on an isolated stack before any rollout claim.

Step 2 — The first real project path on the work-grant lane

What. Walk stages 3 to 7 of the project path on one explicitly chosen pilot project with a real human issuer and a real agent identity, using the implemented Core work-grant routes and the five gateway tools, in the intended client, with Issue proposals as the grant activity. The pull request that carries the change is ordinary agent activity; attribution of pull requests under a grant is not part of this step. The pilot is the touchstone of this architecture.

Benefit. The "Let this agent work for me" requirement of 2026-10-20 exists as a lived journey, not as source; attribution "agent, working for user, on task" is seen on real activity; the gaps in the journey become concrete tickets instead of design prose.

Depends on.

• Rollout acceptance of the work-grant lane as the runbook requires: native, client and runtime acceptance on an isolated stack, then the production object. The Core production object carries the grant routes in source by its commit subject and the adapter's native fixture (this design did not inspect the Core route files); the lane remains "implemented, not rolled out" until that acceptance.
• A pilot project chosen by its owners, with a member willing to issue grants and an agent identity with the needed existing project access.
• Step 1 is not a hard dependency: until it lands, the pilot's room issue states "management not verified" by convention, because no renderer for the label exists yet.

Not included. Self-service adoption, organization-wide grants, new clients, a new credential helper, a broader client list: the pilot declares its one client and transport path, as the delegation requirements demand.

Acceptance. The first-release criteria of the delegation requirements (docs/AGENT_DELEGATION.md), plus:

1. The issuer never hands a personal token to the agent; the agent uses its own credential throughout.
2. Each stage 3–7 of the path is visible in the pilot project: member list with standing, grant summary, the attributed Issue proposal and its receipt in awaiting_review, the pull request as ordinary agent activity, independent review, acceptance by merge.
3. A withdrawn grant stops new operations and leaves submitted receipts and history intact; a second grant remains usable.
4. A lost submission response is reconciled by readback with the same request key; no duplicate issue appears.
5. Negative checks of the delegation requirements: wrong agent, other project, operation outside the grant, lost project authority, reused approval, misleading attribution.
6. The pilot writes its knowledge as records (step 3's contract may be adopted early by convention) and ends with a handoff issue.
7. Independent review of the run with the retained evidence; no live claim before that review.

Step 3 — Project room v0 and the memory record contract

What. One place per project where the conversation, the current decisions, the active and withdrawn grants, the open questions and the handoffs are visible together, built on native primitives: a pinned room issue with the decision log and open questions, memory files following the record contract, the handoff template extended with supersession and uncertainty sections, and a small native projection of participant standing (kind, management status). The room is bound to the project; it has no feed and no ranking.

Benefit. Stage 9 of the path becomes real: a newcomer resumes from one URL with the rights they hold, sees current versus superseded decisions and dated evidence, and finds who manages each agent. The conversation lives where authority and memory live.

Depends on.

• The artifacts of step 2 (a real project with grants, receipts and records) as the first content.
• Template changes in the laboratory repository (handoff template, memory entry layout) and a room convention; optional gateway validation later.
• Step 1 for the management status in the standing projection; until then the room issue states "management not verified" by convention.

Not included. A separate community platform, federation, a vector or graph index, cross-product account links, a native room page in Core (alternative A2 d, evaluated after v0 has carried one real project).

Acceptance.

1. A fresh human member and a fresh agent identity with member access resume the pilot project from the room alone after the original session has ended, and correctly name the current decisions, the open questions and the active grants. A separate public-only run is recorded and is expected to see only public records, because handoffs and records are private by default.
2. Two conflicting records are visible as disputed with their sources; the newest is not presented as current.
3. A record with an old evidence date is displayed as old; a record without sources is displayed as opinion.
4. A private repository with private handoffs cannot be switched to public without the check in the memory contract firing (convention test first, tooling when available).
5. Every participant in the room shows kind and management status; no mint note and no copied description appears as a relationship.
6. Independent review of the room on the pilot project, with a written list of what a newcomer could not find.

Ordering and what is explicitly not now

• Steps 1 and 2 in parallel; step 3 after step 2 has produced real content. No step waits for a date.
• Not added by this pilot: a separate community platform (A2 b), a shared account database across products (A4 c), mandatory runtime rotation (A5 b), a dedicated knowledge store (A3 b), federation and preservation (their own documents).
• The separately authorized Commons/OIDC work continues on its own lane; the project-room experiment neither replaces the broader Commons home nor prohibits verified sign-in between the products.
• Each step ends with an independent review and a native acceptance on an isolated stack before any live statement; source and tests are not rollout.