Repository navigation
Roadmap
The server roadmap project tracks delivery. Issues contain scope and acceptance checks; this page explains sequencing. These are planned outcomes, not promised dates.
Finish repeatable cross-platform validation and clean-host release installation first. Recovery, operator experience, credential boundaries and provider failures are release gates, not optional polish.
- #5 — Track AI provider health and task outcomes without exposing prompts or credentials
- #9 — Verify streaming chat, approvals and terminal behavior across SSH clients
These capabilities are proposals. They are not part of the current supported deployment contract.
- #6 — Define portable application bundles and verified artifact installation
- #7 — Design public TLS ingress and certificate renewal
- #8 — Define cluster ownership and failure semantics before adding automatic placement
- #12 — Add account-scoped Cloudflare DNS and managed tunnel integration
- #13 — Add a native Resend provider with scoped credentials
- #14 — Build source releases in isolated workers
- #15 — Define application-scoped cache, durable state and event services
- #16 — Provide web application templates and versioned static assets
- #17 — Separate core adapters into independently upgradeable services
- #18 — Package a bootable Linux appliance after binary release validation
- #19 — Define optional Git hosting and artifact registry modules
- #20 — Publish a versioned operator API before native Apple clients
- #28 — Add native AI provider adapters and official account sign-in
- #1 — Publish reproducible macOS and Linux release packages — see issue acceptance evidence.
- #2 — Keep macOS and Linux validation on the same release commit — see issue acceptance evidence.
- #3 — Exercise recovery under sustained load and storage failures — see issue acceptance evidence.
- #4 — Make SSH authentication failures understandable to operators — see issue acceptance evidence.
- #10 — Validate Vault recovery, scoped access and credential rotation — see issue acceptance evidence.
- #11 — Add continuous secret scanning and a credential incident runbook — see issue acceptance evidence.
- Validate and package the existing single-node runtime before expanding its platform surface.
- Define release bundles before remote artifact installation, source builds and web assets.
- Define TLS and route ownership before public ingress integration. Cloudflare remains optional.
- Define cluster authority, fencing and partition behavior before automatic placement or replicated state.
- Stabilize typed operator APIs before native Apple clients. Appliance and bundled hosting work follow a reliable binary distribution.
- Todo: scoped work or a proposal; this does not imply implementation.
- In Progress: an active implementation or validation effort, with a linked branch or pull request where available.
- Done: acceptance checks have evidence. A passing build alone does not prove deployment or recovery.
Pull requests should link their issue. Before closing an issue, record the tested revision, relevant checks and any deployment verification. Keep remaining gaps open rather than silently narrowing acceptance. Use the versioned repository documentation for exact behavior and this wiki for navigation.
See Delivery status for the current public release and website handoff. Start architectural changes with an issue and follow Contributing.
See AI framework plan for the source-audited capability matrix, delivery order and acceptance journey. Planned features remain open issues; merged recovery is the existing foundation.
P.Industries · Apache 2.0 · Versioned documentation