Tracking Issue: make PowerContext work continuity reliable, explainable, and cross-host

Goal

Turn PowerContext's existing Memory, Handoff, Work Continuity, Experience, Skill, and integration capabilities into one reliable, explainable, cross-host product journey.

This issue is an umbrella roadmap and sequencing control plane. It tracks dependencies, owners, product-critical exit criteria, and independent child work. It does not replace the linked implementation, research, or evaluation Issues.

Roadmap owner: @AlexStocks.

The product center is:

PowerContext turns human-agent work into evidence-grounded, handoff-ready context.

The differentiator is not a standalone Handoff API. It is the combined lifecycle:

1. exact Source evidence;
2. history-preserving Memory and Artifact Revisions;
3. bounded PreparedContext;
4. exact-revision Handoff;
5. exact evidence re-resolution;
6. receiver-declared live-state, capability, and authorization observations;
7. explicit Acknowledge;
8. completion-aware Task Outcome;
9. Candidate and human Review;
10. approval, publication, installation, and execution kept separate.

Trust and authorization boundary

PowerContext validates exact selections, evidence availability, and schema invariants. It records receiver checks in a Handoff Receipt.

Receiver capability and authorization checks are untrusted self-attestations from the receiving host. They do not:

• authenticate the receiver;
• grant execution authority;
• prove that credentials or permissions exist;
• replace current system/developer instructions, the current user request, or live permission checks.

confirmed means the receiver supplied a schema-valid observation. It does not mean PowerContext performed authentication or ACL enforcement.

A Handoff Receipt never grants tools, network access, credentials, or permission to execute the next action.

Status snapshot

Last refreshed: 2026-08-26.

The linked Issue or PR is the live source of truth. This table is a dated roadmap snapshot.

Work	Live state	Owner / implementation	Roadmap role
#1297	open	PR #1303 open	Memory Revision integrity
#1319	open	assigned; PR #1344 open	transport safety
#1320	open	assigned	existing OceanBase schema upgrade
#1321	open	assigned	bounded Memory capacity/latency
#1322	completed	PR #1325 merged	bounded Runtime scope caches
#1219 / #1238	unresolved	#1238 open draft, review required	Project sharing / Workstream isolation
#1298	open	assigned	local Server availability and service installation
#1301	open	PR #1311 open	multi-host Setup
#1313	open	PR #1314 open	Doctor integration overview
#1302	completed	PR #1304 and PR #1334 merged	Review Inbox, Skills Library, and docs
#1338	open	unassigned	integration capability alignment
#1328	open	PR open	immutable evaluation baselines

Scope dependency

Single-Workstream Work Contract, Handoff, Acknowledge, Task Outcome, and Work Continuity behavior can be audited independently of #1238.

#1238 remains a dependency for:

• the final Project/Workstream product model;
• Project-level context sharing;
• cross-Workstream context composition;
• Workstream discovery, grouping, and binding;
• any acceptance claim that spans different Workstreams rather than continuing one exact Workstream.

The roadmap must not describe all Work Continuity as blocked by #1238, and it must not describe the unresolved Project-sharing contract as accepted.

Integration contract

“Priority hosts” is not a contract. Repository directories, README tables, released CLI commands, master-only integrations, framework adapters, evaluation harnesses, and open PRs can describe different sets.

The versioned repository contract is tracked in:

• #1357 — publish a versioned integration capability manifest.

The manifest must distinguish:

Integration kind

• agent_host
• framework_adapter
• evaluation_harness

Availability

• released
• master_only
• experimental
• proposed
• unsupported

Capability

At minimum:

• Memory read/write;
• Source capture;
• Context injection;
• flush/checkpoint;
• Work Contract;
• Handoff;
• Acknowledge;
• Task Outcome;
• Experience/Skill;
• Candidate Review;
• External Skill;
• pre-compaction capture;
• slash command;
• persistent Workstream binding.

Minimal/Recommended/Full must be derived from, or validated against, the capability set. The first contract is a versioned repository manifest validated against implementation, tests, CLI registration, and maintained docs—not a new stable public HTTP API.

Framework adapters and evaluation harnesses must not be counted as Agent hosts. Released and master-only host runs must be reported separately.

Delivery principles

• Reuse existing Issues and PRs; do not create duplicate branches for assigned work.
• Resolve data integrity, transport safety, migration, performance, and bounded-resource risks before expanding related public promises.
• Keep Source, Memory, Handoff, Outcome, Experience, Skill, approval, publication, installation, and execution as separate authority boundaries.
• Preserve fail-open recall behavior, but never treat authorization failures as ordinary fail-open recall failures.
• Define success through observable scenarios, not tool counts.
• Use common benchmarks and PowerContext-native continuity scenarios.
• Do not present competitor self-reported benchmark results as reproduced evidence.
• Keep changes independently reviewable.

Product critical path

The product critical path is separate from product feature, research, and evaluation child work.

Phase 0 — reliability and contract baseline

Target: weeks 1–2.

Existing implementation work:

• #1297 / #1303 — authoritative Memory Revision integrity.
• #1319 / #1344 — shared plaintext transport policy.
• #1320 — existing OceanBase/MySQL schema upgrade path.
• #1321 — bounded Memory manifest/storage/latency contract.
• #1322 / #1325 — bounded Runtime scope caches.
• #1219 / #1238 — Project sharing and Workstream isolation decision.
• #1298 — local Server availability and service installation.

These items are assigned or have active implementation work. New contributors must coordinate in the original Issue and must not start duplicate fixes.

Contract reconciliation:

• Audit RFC 1223 against current models, OpenAPI operations, Server routes, Handoff Report UI, integration guidance, and tests.
• Decide and record whether RFC 1223 is Draft, Accepted, or Experimental.
• Reconcile only the Project/Workstream-dependent parts with #1238.
• Distinguish current master behavior, released behavior, and maintained documentation.
• Create focused follow-up Issues only for verified gaps.

Phase acceptance:

• Malformed Memory Revisions cannot produce search/read disagreement.
• Runtime caches remain bounded under caller-controlled scope growth.
• Existing OceanBase schemas are migrated or fail closed with actionable guidance.
• Unsafe remote plaintext HTTP configurations are rejected by the owning transport surface.
• Memory append/list operations have an explicit observable capacity contract.
• Work Continuity status is consistent across RFC, OpenAPI, code, tests, and public documentation.

Phase 1 — reliable daily use

Target: weeks 2–4.

Related work: #1298, #1301, #1313, #1333, #1311, and #1314.

• Surface content-free, bounded, deduplicated server_unavailable diagnostics in supported Agent hosts.
• Implement shared personal-service facts before correlated Doctor logic.
• Implement powercontext service install/status/uninstall through the accepted distribution/service-install boundary.
• Qualify native adapters only after matching-runner lifecycle tests.
• Keep unsupported and not_installed honest and advisory.
• Provide one explicit Setup path for one or more detected Agent hosts.
• Make Doctor report Server, integration, capture, recall, guidance, registration, manager, liveness, readiness, and recovery facts.
• Define the no-inference-provider capability profile.
• Document data, configuration, log, recovery, reconciliation, and uninstall boundaries.

Acceptance journey:

clean machine
  -> install PowerContext
  -> detect and select an Agent host
  -> install the integration
  -> install/start the local service
  -> Doctor reports exact status
  -> store one project decision
  -> a new Session recalls it

Suggested product target: first cross-Session recall within 10 minutes of starting installation.

Phase 2 — cross-host Work Continuity

Target: weeks 3–6.

Dependencies:

• #1357 — versioned integration capability manifest.
• #1358 — deterministic cross-host Work Continuity acceptance.

Completed supporting work:

• #1302 — Experience and Skill Review workflow.
• #1304 — Review Inbox and Skills Library.
• #1334 — reviewed Experience and Skill documentation.

Remaining product work:

• Keep the default MCP tool profile compact.
• Select the first host pair from the versioned manifest.
• Report released and master-only host qualification separately.
• Show exact evidence, Revision, delivery status, drift, and conflicts.
• Keep Candidate approval and Skill publication separate.

Required scenario:

Host A creates a Work Contract
  -> Host A performs partial work
  -> Host A prepares and commits an exact Handoff
  -> Host B receives no Host A Session transcript
  -> PowerContext re-resolves exact evidence
  -> Host B records untrusted receiver self-attestations
  -> Host B acknowledges the exact Revision
  -> Host B records a Task Outcome
  -> Work Continuity shows outcome covered only for the exact Receipt
  -> an Experience Candidate may be generated
  -> a human reviews it
  -> an approved Revision is published separately

Product acceptance:

• Host B does not depend on Host A's Session transcript.
• Unavailable evidence cannot be accepted.
• A diverged workspace does not silently execute an old next action.
• Receiver checks are explicitly marked untrusted and do not grant authority.
• accepted does not mean completed.
• Outcome coverage requires the exact accepted Receipt.
• failed, timed_out, unavailable, skipped, cancelled, and unknown are not upgraded to passed.
• Candidate cannot approve itself.
• Approval does not publish, install, or execute a Skill.

Independent product feature work

These features have their own contracts and acceptance. They remain visible in this roadmap but are not folded into one all-or-nothing core product exit condition.

Explainable PreparedContext

• #1356 — RFC for explainable PreparedContext Receipts and progressive disclosure.

The RFC owns:

• Receipt schema and bounds;
• policy version and output digest;
• selected exact references;
• omitted counts/reasons;
• retrieval/rerank/fallback states;
• non-determinism marking;
• privacy and retention;
• compatibility;
• progressive inspection.

Context Inspector implementation requires an accepted #1356 RFC and a separate implementation Issue.

Independent research work

Research work has separate owners and does not block the product critical-path exit unless it discovers a correctness or safety blocker.

Source identity and immutable observation

• #1240 — Source integration shape; currently assigned.
• #1300 — explicit, default-off pre-install Host prompt import.

#1240 owns the bounded validation Source integration. Do not open a parallel GitHub Source pilot while #1240 is active without coordinating with its owner.

Research acceptance remains in #1240:

• logical Source identity versus immutable observation identity;
• exact old evidence after external mutation;
• Capture/Ref/Hybrid decision;
• one bounded integration validation;
• no Connector Marketplace or background sync in the first slice.

Independent evaluation work

Evaluation work has its own contracts, artifacts, and acceptance. A benchmark subset is never a product completion claim.

• #1263 — shared benchmark coverage and infrastructure.
• #1328 — immutable single-arm baseline comparisons.
• #1359 — bounded LongMemEval-V2 workload.

Report accuracy/task success together with latency, Context bytes/tokens, ingestion cost, exact citation availability, abstention, and failure categories.

Do not add persistent L0/L1 or temporal public schema fields before independent evidence and an accepted RFC support them.

Product critical-path exit criteria

The core product path is complete when:

• all Phase 0 correctness and contract gates are closed or explicitly deferred with recorded risk;
• one supported platform passes the persistent personal-service journey;
• #1357 provides a versioned, validated integration manifest;
• at least one released or explicitly master-only host pair passes #1358 with exact version reporting;
• receiver capability/authorization wording remains an untrusted observation rather than an authorization grant;
• Review, approval, publication, installation, and execution boundaries pass focused acceptance;
• no stale/diverged Handoff next action is silently executed;
• no unauthorized automatic approval, publication, installation, or execution is observed.

Umbrella roadmap completion

#1352 can close when:

• the product critical-path exit criteria above are met;
• every remaining product feature, research, and evaluation item has an independent Issue, owner or explicit unassigned status, acceptance criteria, and current state;
• unfinished independent research/evaluation remains tracked in its child Issue and is not misrepresented as completed.

Completion of #1356, #1240, #1300, #1263, #1328, or #1359 is not automatically required to close the product critical path unless that work discovers a blocker or is explicitly promoted into the critical path by a recorded decision.

Explicit non-goals

• A complete Context Graph or mandatory graph database.
• Team/User/Role/Agent ACL before a separate authentication/authorization design.
• Treating receiver self-attestation as authentication or authorization.
• An OpenAI/Anthropic proxy as the default integration path.
• A built-in Agent Runtime or multi-Agent Orchestrator.
• A Connector Marketplace before one Source pilot proves the contract.
• Treating Session End or Stop as task completion.
• Automatic Handoff commit.
• Automatic Candidate approval.
• Automatic Skill publication, installation, or execution.
• Treating Branch, Session, model, or Agent identity as Workstream identity.
• Exposing dozens of MCP tools by default.

First owner action

All identified Phase 0 implementation bugs and service work are assigned or have active PRs. The first non-duplicative owner action is:

Audit and reconcile the Work Continuity contract before starting another implementation branch.

Deliverables:

1. Read RFCs 0019, 0028, 0048, 0051, 0082, 1223, and the scope RFC in #1238.
2. Inventory implemented Work models, OpenAPI operations, Server routes, Handoff Report behavior, integration guidance, and focused tests.
3. Produce an evidence table: specified, implemented, released/documented, missing, or conflicting.
4. Recommend Draft, Accepted, or Experimental for RFC 1223 with evidence.
5. Identify the minimum docs/RFC fixes and genuinely missing implementation Issues.
6. Do not implement #1297, #1298, #1319, #1320, #1321, or other assigned work in parallel.
7. Run make docs-test for documentation changes and focused Work/Handoff tests for code-contract claims.

Safe stop:

• If status depends on an unresolved #1238 decision, report the exact dependency and stop before changing the public Scope contract.
• This roadmap does not authorize merging #1238, resolving reviews, or modifying another contributor's branch.