Skip to content

HeyAira roadmap after the server release

This page is the current planning view. It separates verified capability, work in progress, and future proposals so an agent does not confuse an old implementation note with the next approved step.

Current baseline

The server foundation is deployed and operational:

  • public MCP endpoint: https://mcp.heyaira.eu/mcp;
  • project-scoped OAuth 2.1 with PKCE and protected Bearer compatibility;
  • durable memory, decisions, tasks, optimistic locking, and work receipts;
  • bounded startup recovery through server_identity and continuity_context;
  • Git references and allowlisted, commit-pinned document reads;
  • GitHub repository binding and read-only CI status observation;
  • GitHub/Git remains the source of truth for code and files.

The verified production release recorded in HeyAira is:

3d2e6828f7786dd0f9975ce10b011b8f0c20d5c7

This baseline does not mean that every future client workflow has been validated. The server contract and the real harness workflow are separate acceptance targets.

Next milestone: Continuity v0.1

The next product milestone is a real cross-client continuity experiment, not another general-purpose server feature.

Acceptance flow

  1. Session A creates a synthetic decision and task in HeyAira.
  2. Session A ends without sending a transcript or a manual summary.
  3. Session B, using a separate client session, calls server_identity and continuity_context, reads the selected task, and continues the work.
  4. Session B records a handoff and work receipt with the actual test result.
  5. Session C independently verifies the final task, receipt, and Git reference.

The public version of this test passed on 2026-09-20 after the smoke scripts were aligned with the deployed memory_add summary contract. The run used the production MCP endpoint and a project-scoped test credential with synthetic markers only.

What counts as success

  • no context is copied between sessions;
  • the sessions use the same authenticated project;
  • the selected task is not recreated in another project;
  • the final receipt identifies the worker, tests, and repository checkpoint;
  • a stale concurrent update is rejected atomically;
  • a fresh verifier can explain the result using HeyAira and Git alone.

Recorded public results:

  • continuity_protocol_status=passed;
  • multi_client_status=passed;
  • idempotent retries and stale-version rejection passed;
  • the test scripts were merged to main in 8bb083c0c99ee480c075159ccae5bf0338684d39.

Backup closure

Backup is a reliability gate for the durable state layer. The repository has the heartbeat, encrypted pg_dump/age/R2 worker, retention planner, health check, and isolated restore implementation. Production activation is not claimed while any of the following remain open:

  • the exposed R2 credential has not been rotated and verified safe;
  • the backup service remains paused;
  • a real encrypted object and manifest have not been re-verified after the rotation;
  • an isolated restore from that object has not been evidenced;
  • the application alert path has not passed failure and recovery drills;
  • an independent monitor has not detected both failure and stale success.

SES inbox delivery is evidence for the mail provider, not proof that the backup application emits correct alerts. APNs delivery is a separate Bridge scope and is not a backup completion criterion.

After the two gates pass

Only after Continuity v0.1 and backup closure should we prioritize:

  1. multi-project account and project-selection UX;
  2. explicit client/project connection profiles;
  3. reusable agent startup and finish-session integrations;
  4. controlled GitHub write operations such as issues or pull requests;
  5. task leasing, worker offers, and a runner;
  6. questions and responses addressed to a prior work session;
  7. subscriptions and provider-specific harness adapters.

These are separate layers. A queue, router, subscription, or wake-up adapter must not be presented as part of the current continuity guarantee.

Explicitly not the next step

  • Do not build model routing before the continuity hypothesis is accepted.
  • Do not treat AGENTS.md, skills, or hooks as a universal guarantee that every harness performed a write; the server can enforce write correctness, while clients provide workflow guidance.
  • Do not enable APNs, SES production notifications, or backup scheduling based only on local tests.
  • Do not store conversation transcripts, credentials, or repository contents in HeyAira.

Documentation rule

Every public behavior change updates its source, tests, tool contract, and the human/agent documentation in one pull request. PROJECT_STATE.md records evidence and constraints; this page records the current order of work. A proposal remains a proposal until a separate HeyAira decision accepts it.