You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
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.
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.
#1240 owns the bounded validation Source integration. Do not open a parallel GitHub Source pilot while #1240 is active without coordinating with its owner.
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.
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:
The differentiator is not a standalone Handoff API. It is the combined lifecycle:
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:
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.
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 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:
The manifest must distinguish:
Integration kind
Availability
Capability
At minimum:
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
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:
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:
Phase acceptance:
Phase 1 — reliable daily use
Target: weeks 2–4.
Related work: #1298, #1301, #1313, #1333, #1311, and #1314.
Acceptance journey:
Suggested product target: first cross-Session recall within 10 minutes of starting installation.
Phase 2 — cross-host Work Continuity
Target: weeks 3–6.
Dependencies:
Completed supporting work:
Remaining product work:
Required scenario:
Product acceptance:
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
The RFC owns:
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 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:
Independent evaluation work
Evaluation work has its own contracts, artifacts, and acceptance. A benchmark subset is never a product completion claim.
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:
Umbrella roadmap completion
#1352 can close when:
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
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:
Deliverables:
Safe stop: