oceanbase / oceanbase/powercontext

acceptance: verify cross-host Work Continuity

Open
#1,358 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
1.1k
Forks
212
Avg merge
1d 11h
Merged PRs (30d)
199

Description

Goal

Add a deterministic cross-host Work Continuity acceptance scenario that proves a receiver can continue exact work without access to the sender's original Session transcript.

Parent roadmap: #1352.

Dependency: #1357. Related integration alignment discussion: #1338.

This issue is a product acceptance contract. It is not an instruction to expose identical tools in every host.

Scenario

At minimum:

  1. Host A creates a Work Contract for one Workstream.
  2. Host A performs partial work and records exact evidence.
  3. Host A prepares and commits an exact Handoff Revision.
  4. Host B receives only the current request, live workspace, PowerContext access, and the exact Handoff selection—not Host A's Session transcript.
  5. PowerContext re-resolves exact evidence.
  6. Host B records receiver-declared live-state, capability, and authorization observations.
  7. Host B acknowledges accepted, needs_clarification, or declined.
  8. If accepted, Host B performs one authorized next action and records a Task Outcome.
  9. Work Continuity shows accepted/awaiting_outcome and then covered only when the Outcome references the exact accepted Receipt.
  10. Eligible Outcome evidence may produce an Experience Candidate, but Review and publication remain separate.

Trust and authorization boundary

Receiver capability and authorization checks are untrusted self-attestations recorded by the host.

PowerContext:

  • validates the exact selection;
  • resolves evidence availability;
  • validates schema invariants;
  • preserves the observations in the Receipt.

PowerContext does not:

  • authenticate the receiver;
  • grant execution authority;
  • prove that credentials or permissions exist;
  • replace current instructions or live permission checks.

The acceptance report must use this wording.

Supported host selection

The scenario must select hosts from the versioned capability manifest:

  • both hosts must be classified as agent_host;
  • both must have a concrete availability state;
  • the sender and receiver must expose the required Recommended-profile capabilities;
  • released and master-only runs must be reported separately;
  • framework adapters and evaluation harnesses must not be counted as Agent hosts.

The first implementation may qualify one host pair. It must not claim all-host parity.

Acceptance criteria

  • Host B does not receive Host A's Session transcript.
  • The Handoff selection is exact; latest is resolved and frozen before acknowledgement.
  • Unavailable evidence cannot be accepted.
  • A diverged workspace cannot silently execute the old next action.
  • needs_clarification and declined require a reason.
  • accepted requires complete receiver self-attestations, clearly marked untrusted.
  • accepted does not mean completed.
  • Only an Outcome referencing the exact accepted Receipt changes outcome coverage to covered.
  • failed, partial, timed_out, skipped, unavailable, cancelled, and unknown remain distinct.
  • Candidate creation does not approve, publish, install, or execute an Experience or Skill.
  • The report records exact PowerContext revision, integration revisions, host versions, database profile, and test evidence.
  • SQLite is required for the first deterministic slice; OceanBase parity follows the existing E2E database policy.

Non-goals

  • An Agent-to-Agent transport standard.
  • Copying complete transcripts between hosts.
  • Treating a Host, Session, branch, or model as Workstream identity.
  • Authenticating or authorizing the receiving Agent.
  • Requiring identical UI, hooks, slash commands, or tool names.
  • Automatically executing Handoff next actions.

Deliverables

  • Scenario fixture;
  • deterministic harness;
  • per-step evidence;
  • concise report;
  • capability-manifest validation;
  • one negative mutation or equivalent discriminative proof for stale/diverged continuation.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with dependency #1357 and the versioned capability manifest, then trace the existing deterministic E2E database policy for the required SQLite slice. Build the scenario fixture and harness around the listed acceptance steps, including per-step evidence, the required report wording, and a stale or diverged-workspace mutation. Done means the report proves exact handoff selection, receiver boundaries, outcome coverage, and separate host qualification without claiming all-host parity.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, sqlite
Domain
backend, databases, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.