This repository was archived by the owner on Nov 7, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 7, 2026. It is now read-only.
Roadmap: Elevate Synapse to a market-leading managed beta #71
Description
Objective
Elevate Synapse into a focused, dependable, commercially viable managed beta using evidence-backed release, trust, customer and economics gates.
This is the governing GitHub roadmap. PRODUCT.md is the detailed product/evidence source of truth; BACKLOG.md is the technical implementation record.
Current repository state — 2026-09-05
Current main:
b45170409543684a75579a13d7bdd6d8f8ffe8e8
This is not the final pre-pilot candidate.
PR #95 is now ready for an explicit merge decision, not draft, on exact reviewed head:
431d7da80c9bac56aa16423ab61a235a176b6fd8
PR #95 exact-head evidence:
- Codex final review: no major issues;
- Ashbi Local CI: passed isolated install, Prisma generation, TypeScript, ESLint, focused auth/navigation/security tests, and production Next build;
- GitGuardian: passed, no secrets;
- all inline recovery review threads resolved;
- PostgreSQL documentation confirms normal-operation OIDs are 16384+, supporting the high-OID user-created system-schema contamination guard;
- hosted GitHub
CI Build / Build: zero-step failure from the continuing runner-infrastructure incident.
Ashbi Local CI does not directly execute tests/backup-restore.test.ts; those recovery contract assertions were separately checked against the exact branch text, while Local CI supplies compile/lint/build compatibility evidence.
PR #95 remains unmerged. If explicitly merged, the resulting main SHA becomes the repository candidate and all exact-SHA/image/evidence references must be rebound to that result.
Success definition
- Five approved target users complete the no-payment two-week pilot.
- At least 4/5 understand the goals-to-today promise and reach first value within ten minutes.
- At least 4/5 resolve a daily plan on 8/14 days and cite a concrete outcome improvement.
- Export/deletion, reliability, security/privacy, accessibility, recovery, support and rollback gates pass.
- Observed service economics can sustain the approved contribution-margin target.
- No release, pricing, spend, legal commitment, payment collection or outreach occurs without its explicit approval.
Phase 0 — Final RC1 correctness freeze
- fix: reconcile restored upload target during recovery drill #95 implementation/review preparation — exact head
431d7da…is ready for merge decision with clean intended Codex/local/security evidence and resolved review threads. - fix: reconcile restored upload target during recovery drill #95 disposition — obtain explicit merge/reject decision. If merged, refetch
main, freeze the resulting SHA, and rebind P0: Run production Compose image/database smoke and close configuration audit #29/P0: Assemble exact-SHA release approval package and staged rollout #70 evidence. If rejected, document why the current recovery path remains acceptable before P0: Run production Compose image/database smoke and close configuration audit #29.
No #29/#61 recovery evidence or #70 final artifact freeze may run against an intermediate PR head or the stale b451704… candidate.
Phase 1 — Runtime, governance, trust and operations
- P0: Run production Compose image/database smoke and close configuration audit #29 — disposable exact-candidate Compose/image/PostgreSQL/lifecycle/backup/restore proof after fix: reconcile restored upload target during recovery drill #95 disposition.
- P0: Restore application validation for production dependency pull requests #49 Stage A — owner/admin enables PR + one-review governance, stale-approval dismissal, conversation resolution, and force-push/delete protection without requiring the currently non-executable hosted check.
- P0: Restore application validation for production dependency pull requests #49 Stage B/C — after one clean hosted exact-SHA
CI Build / Build, require that check/up-to-date branch and prove enforcement with a harmless test PR. - P0: Complete production operations, backup, monitoring, and rollback evidence #61 — approved host/backup/alerts/responders/retention/RPO/RTO plus restore/rollback evidence.
- P0: Verify external email delivery and complete authentication journey QA #60 — approved external email sender/domain/mailbox plus full verification/reset QA.
- P0: Approve legal and data policy and correct license ownership #62 — owner/legal identity decisions, qualified policy review and correct licence ownership.
- P0: Establish beta support and incident response operations #63 — approved/verified support routes, responders, hours/escalation and participant instructions.
Phase 2 — Rendered and AI validation
- P1: Validate the complete customer lifecycle in rendered browser QA #64 — desktop/mobile/keyboard/failure/recovery/export/reset/delete rendered lifecycle QA.
- P1: Run representative AI task-creation quality, safety, latency, and cost evaluation #67 — evaluate the approved beta AI provider/model, or explicitly limit/disable AI task creation for beta.
Phase 3 — Pre-pilot customer/economics readiness
- P1: Validate goals-to-today positioning and first-value comprehension #65 — prepare Day-0 unaided goals-to-today comprehension/first-value protocol; complete pre-pilot or explicitly incorporate into P1: Run the five-user 14-day managed-beta validation pilot #66 Day 0.
- P1: Validate managed-beta pricing and sustainable unit economics #68 pre-pilot — approve test range, unaided-WTP question order and economics measurement plan. No public price or payment.
- Five approved target participants exist in an external privacy-minimal P01–P05 ledger after explicit outreach/enrolment approval.
Phase 4 — Exact artifact approval
- P0: Assemble exact-SHA release approval package and staged rollout #70 — freeze exact resulting
mainSHA + immutable image digest, assemble the pre-pilot release package, passrelease:validate, and obtain exact staged-deployment approval.
Phase 5 — Managed beta and closeout
- P1: Run the five-user 14-day managed-beta validation pilot #66 — run five-user, 14-day invite-only, no-billing managed beta after P0: Assemble exact-SHA release approval package and staged rollout #70 approval.
- P1: Validate goals-to-today positioning and first-value comprehension #65 — close Day-0 comprehension/first-value evidence if incorporated into P1: Run the five-user 14-day managed-beta validation pilot #66.
- P1: Validate managed-beta pricing and sustainable unit economics #68 post-pilot — replace assumptions with observed WTP/support/service/AI cost evidence and issue approve/revise/reject economics recommendation.
- Make keep/revise/stop decision.
RC1 execution order
- fix: reconcile restored upload target during recovery drill #95 disposition → resulting
mainSHA freeze. - P0: Run production Compose image/database smoke and close configuration audit #29 isolated runtime/recovery proof on that exact SHA/image.
- P0: Restore application validation for production dependency pull requests #49 governance enforcement; Stage A may be applied earlier once separately approved, while Stage B waits for hosted Build recovery.
- P0: Complete production operations, backup, monitoring, and rollback evidence #61 operations evidence.
- P0: Verify external email delivery and complete authentication journey QA #60 external email/auth QA.
- P0: Approve legal and data policy and correct license ownership #62 + P0: Establish beta support and incident response operations #63 qualified participant policy/support model.
- P1: Validate the complete customer lifecycle in rendered browser QA #64 + P1: Run representative AI task-creation quality, safety, latency, and cost evaluation #67 rendered lifecycle and AI validation.
- P1: Validate goals-to-today positioning and first-value comprehension #65 + P1: Validate managed-beta pricing and sustainable unit economics #68 pre-pilot readiness.
- P0: Assemble exact-SHA release approval package and staged rollout #70 exact artifact/staged deployment approval.
- P1: Run the five-user 14-day managed-beta validation pilot #66 14-day pilot.
- P1: Validate managed-beta pricing and sustainable unit economics #68 post-pilot economics and keep/revise/stop decision.
No later phase may silently bypass an unfinished earlier gate.
Dependency rules — no circular gates
- P0: Assemble exact-SHA release approval package and staged rollout #70 does not depend on completed P1: Run the five-user 14-day managed-beta validation pilot #66.
- P0: Assemble exact-SHA release approval package and staged rollout #70 does not depend on completed post-pilot P1: Validate managed-beta pricing and sustainable unit economics #68 economics evidence.
- P1: Run the five-user 14-day managed-beta validation pilot #66 does depend on P0: Assemble exact-SHA release approval package and staged rollout #70 exact-artifact staged-deployment approval.
- P1: Validate managed-beta pricing and sustainable unit economics #68 has two phases: pre-pilot research readiness before P0: Assemble exact-SHA release approval package and staged rollout #70, post-pilot economics conclusion after P1: Run the five-user 14-day managed-beta validation pilot #66.
- Post-beta: Implement approved billing, cancellation, and entitlement recovery #69 is not an RC1 or P0: Assemble exact-SHA release approval package and staged rollout #70 dependency.
Post-beta — Paid lifecycle
- Post-beta: Implement approved billing, cancellation, and entitlement recovery #69 — billing/cancellation/entitlement recovery only after P1: Run the five-user 14-day managed-beta validation pilot #66 closes and P1: Validate managed-beta pricing and sustainable unit economics #68 yields an owner-accepted economics recommendation.
The five-user managed beta remains no-payment. Provider selection, public pricing and payment collection are separate later approvals.
Post-RC1 — Adaptive Planning
Adaptive Planning remains product direction but is excluded from RC1. PR #79 contains the deferred implementation for:
- Post-RC1: build the “My day changed” Adaptive Planning vertical slice #74 — parent
My day changedvertical slice. - Post-RC1: verify deterministic Adaptive Planning prioritization and capacity model #75 — deterministic prioritization/capacity model.
- Post-RC1: verify Adaptive Planning preview, confirm, apply, and safe undo workflow #76 — preview/confirm/apply/safe-undo workflow.
- Post-RC1: verify mobile-first “My day changed” interaction #77 — mobile-first rendered interaction.
- Post-RC1: verify truthful Todo effort, Today deferral, and bounded undo model #80 — effort/deferral/persistence/migration/undo model.
PR #79 must later be rebased onto post-beta main, fully tested, migration-verified and rendered-QA verified before any merge.
Planned post-RC1 loop:
Goals → Today → Execute → Life changes → Adapt → Reflect → Learn → Tomorrow
Initial Adaptive Planning slice remains My day changed, with explainable Keep / Shorten / Move / Drop proposals and explicit confirmation before mutation.
Other frozen PR work
- Dependency PRs chore(deps): bump the production-dependencies group across 1 directory with 3 updates #59, chore(deps): bump docker/login-action from 3 to 4 #72 and chore(deps-dev): bump @humanfs/node from 0.16.7 to 0.16.8 #73 remain outside RC1 unless a release-critical security reason is demonstrated.
- Overlapping developer/agent contract drafts chore(dev): establish reproducible environment contract #91–chore: establish reproducible development contract #93 remain post-RC1 and should later be reconciled into one current-main maintenance PR rather than merged independently.
Issue lifecycle rules
Every issue remains one of:
- Completed and verified — acceptance evidence exists; close it.
- Completed awaiting verification — implementation exists; keep open with exact missing evidence.
- Blocked / approval-required — keep open with exact decision/action.
- Customer-validation pending — keep open until measured participant evidence exists.
- Post-beta / Post-RC1 — keep open but explicitly outside current release gates.
Operating rules
- RC1 accepts release blockers, security/reliability corrections and verification work only.
- Proposed, implemented, verified, released and customer-validated are not interchangeable.
- Evidence must bind to the exact final repository SHA and deployed image digest where applicable.
- No customer content, credentials, raw tokens or participant identities belong in GitHub evidence.
- Approval-required labels preserve the owner boundary; preparation does not authorize the external action.
- A complete release checklist is never deployment authorization.
Next transition
The repository-side planning/preparation for this gate is complete. The next unresolved transition is the explicit disposition of ready PR #95. After a merge, refetch/freeze the resulting main SHA and continue with #29; without a merge approval, do not execute #29 against the old candidate.
Activity
camster91 commentedon Sep 4, 2026
RC1 integration plan prepared 2026-09-03 — planning only; no merge authorization implied.
Open RC1 preparation PRs:
.github/workflows/ci.yml+ test).package.json.package.json.package.json.Recommended eventual integration order after explicit merge approval and review:
package.jsonscript additions are combined rather than conflicting/overwriting one another.After every merge, revalidate the new exact head; do not inherit a green result from an earlier PR SHA. Hosted CI is currently blocked by zero-step runner-allocation failures, so this sequence is not yet merge-ready evidence.
Branch protection, provider/DNS setup, production infrastructure, legal publication, deployment and pilot outreach remain separate approval gates.
camster91 commentedon Sep 4, 2026
RC1 reconciliation after approved merges — 2026-09-04
Current
main:b16ca80a28e96ad22a6d2cae3acb4f920466712d.Merged code-side preparation:
prisma migrate deploy(governance still open).Prepared and not merged:
Hosted validation remains unavailable: latest retries for PR #87 and PR #88 again created Build/Image jobs with zero executed steps, so they provide neither code pass nor code failure evidence.
Remaining RC1 blockers are now predominantly evidence/governance/owner decisions rather than product feature implementation: #29 runtime Compose proof, #49 branch protection/review enforcement, #60 external sender/mailbox/DNS QA, #61 operational infrastructure evidence, #62 legal/identity decisions and qualified review, #63 support-route decisions/proof, then #70 exact-artifact approval package.
No deployment, production migration, DNS/provider purchase/configuration, policy publication, participant communication, billing, or repository protection change was performed.
camster91 commentedon Sep 4, 2026
RC1 integration checkpoint (2026-09-04): the preparation PR sequence is now fully merged through current
maina09a91ac1ff90da23f3c12c397858ec0a460cd03.Merged preparation:
The roadmap is now evidence/decision-bound rather than implementation-bound. Remaining P0 work is real runtime/external/governance proof for #29, #49, #60, #61, #62, #63, then #70. Fresh hosted CI on the final main SHA still fails before checkout with zero executed steps, so no release validation is inferred. Adaptive Planning remains post-RC1 and should not expand the frozen release candidate.
camster91 commentedon Sep 4, 2026
Roadmap integration review — 2026-09-04
Current RC1 code line is now
main@0c05e7037b5d07029401aad2d6515ef6c243a08c.Merged as release-safe maintenance:
Reviewed and intentionally excluded from RC1:
The open PR queue now contains only that deferred #79 feature PR. RC1 should remain frozen at the current integrated line except for evidence-driven release/trust fixes.
camster91 commentedon Sep 4, 2026
RC1 owner-decision packet — current candidate
0c05e7037b5d07029401aad2d6515ef6c243a08cAll code-side RC1 preparation is integrated. The remaining release work should now proceed as separate, narrowly scoped approvals/evidence gates rather than more feature implementation.
A. #49 repository governance
Recommended: protect
main; require PRs, one qualified approval,CI Build / Build, stale-approval dismissal, no force push/delete. Keep image validation path-scoped rather than universally required.Approval scope if chosen: repository governance only. No deployment, production, DNS, billing, or customer impact.
B. #29 disposable Compose proof
Recommended: run the exact candidate only in an isolated non-production Docker environment, using disposable DB/uploads/outbox state. Prove migration, readiness, lifecycle, backup, restore, and cleanup. Customer impact: none; expected incremental cost: $0 CAD if using an already approved host.
Approval scope if chosen: create/delete disposable containers, networks, volumes, database, and synthetic account data only. No production/public host mutation.
C. #60 external authentication email
Recommended: use the already implemented Resend adapter with a dedicated Synapse sender identity on an owner-approved domain/subdomain and only operator-controlled test mailboxes for QA. Verify SPF/DKIM/DMARC and rendered verification/reset journeys before any participant invite.
Approval scope if chosen: provider/domain/mailbox configuration and operator-only test messages. Customer addresses/contact remain separately prohibited.
D. #61 operations objectives
Recommended beta defaults: RPO 24h; RTO 4h; daily encrypted off-site backups; 30-day retention subject to qualified policy review; alerts for unhealthy instance, elevated request errors, backup failure, disk >80%; one primary + one backup responder; no public SLA.
Approval scope if chosen: these operating objectives only. Actual provisioning, backup upload, alert delivery, destructive restore, rollback, or production access remains action-time approval.
E. #63 support model
Recommended: one monitored email-based primary route; urgent access/data-loss/deletion/privacy path in the same monitored system with explicit urgent routing if desired; one primary + one backup responder; stated coverage hours/time zone; no SLA; both responders may pause the pilot on Sev 1.
Approval scope if chosen: operating model only. Creating/publishing channels or contacting participants remains separate.
F. #62 legal/data ownership
No defaults should be inferred. Owner must explicitly provide: operating identity, jurisdiction, privacy owner/contact, copyright holder/year, host/data region, participant eligibility, and policy effective date. Qualified review must approve privacy/terms/retention/provider/AI/analytics/support wording before publication.
P1 evidence gates
#64 rendered browser QA; #65 comprehension/first-value testing; #66 five-user 14-day pilot; #67 approved-provider AI evaluation; #68 willingness-to-pay and observed economics. #69 remains post-beta and does not block the no-payment pilot.
Rule
Each approval is independent. Approval of one item must not be interpreted as approval of another, and none of the above by itself authorizes production deployment or public launch.
camster91 commentedon Sep 4, 2026
RC1 dependency freeze — 2026-09-04
Full open-PR audit complete.
Frozen candidate remains
0c05e7037b5d07029401aad2d6515ef6c243a08c.Open PRs intentionally excluded from RC1:
@anthropic-ai/sdk,lucide-react,zod): post-beta; changes provider/API/type surface and would expand verification scope.docker/login-actionv3 → v4: post-beta; major action-runtime change requiring runner v2.327.1+ and not a fix for the current runner-allocation incident.@humanfs/nodedev/transitive update: post-beta; no release-critical benefit.No other open pull requests exist. None of these should change the exact RC1 candidate before the beta decision unless a specific release-critical/security justification is documented and explicitly approved.
camster91 commentedon Sep 4, 2026
2026-09-04 control-plane reconciliation prepared
Documentation-only PR #94 now reconciles the repository control plane to this governing roadmap without changing application code, workflows, dependencies, infrastructure, or release behavior.
PR #94 updates only:
PRODUCT.md— current RC1 product/evidence/release truth;BACKLOG.md— current technical implementation/verification states;README.md— canonical navigation and managed-beta boundary.It removes stale PR #55 / hosted-green-CI / obsolete dependency-PR claims and records the current baseline
0c05e7037b5d07029401aad2d6515ef6c243a08c, open RC1 evidence gates, post-beta billing, post-RC1 Adaptive Planning, and frozen dependency PRs #59/#72/#73.Effective diff is three documentation files only. PR #94 is reviewable and mergeable but remains unmerged. If it is eventually merged before final release freeze, #70 must bind release evidence to the resulting exact commit SHA rather than the older runtime baseline SHA.
GitHub-hosted CI on #94 again failed before checkout with zero executed steps (
steps:null), matching the existing hosted-runner incident rather than exposing a new application failure.camster91 commentedon Sep 4, 2026
Repository-maintenance queue reconciliation — 2026-09-04
New open draft PRs #91, #92, and #93 were reviewed after #94 merged. They are independent/divergent pre-#94 branches with overlapping environment/agent-contract scope; #93 also changes canonical CI. None is RC1 release-critical.
RC1 disposition: keep all three draft and outside the current candidate
b45170409543684a75579a13d7bdd6d8f8ffe8e8. Post-beta, reconcile them into one current-main repository-maintenance PR rather than merging competing contracts independently. This does not change the roadmap execution order; #29 remains next.camster91 commentedon Sep 5, 2026
RC1 checkpoint — recovery correctness before #29 execution
The roadmap remains at #29, but execution is temporarily held on focused recovery fix PR #95.
Review found the current restore drill can reconcile
./uploadsinstead of the files just restored intoRESTORE_UPLOAD_DIR. Because that can create false-positive restore evidence, #29 must not run against current candidateb45170409543684a75579a13d7bdd6d8f8ffe8e8until #95 or an equivalent fix is accepted.PR #95 is intentionally narrow: restore/upload reconciliation correctness + static contract coverage only. No new product scope. If merged, refresh the exact RC1 repository SHA and continue the existing order: #29 → #49 → operations/email/policy/support → rendered/AI validation → pre-pilot readiness → #70 → #66 → #68 closeout.
camster91 commentedon Sep 5, 2026
RC1 owner-decision packet — prepared, not approved
Once #95/#29/#49 are cleared, the remaining external gates can be unlocked from one explicit decision set. Nothing below is inferred or authorized by this comment.
A. Managed-beta operations (#61)
Recommended five-user defaults:
B. Authentication email (#60)
Recommended default:
$0 if existing approved plan permitsrequired before configuration.C. Support/incident model (#63)
Recommended five-user model:
D. Legal/data decisions (#62)
Must be explicitly supplied; do not infer from repo/profile history:
Qualified review and a separate publication approval remain required after these decisions.
E. AI validation (#67)
Before live provider evaluation:
Suggested approval format
When ready, Cameron can approve or edit the recommendations in one message, for example:
Approve A defaults; Resend for B with [domain/sender/mailbox/operator/spend]; C with [routes/responders/hours/time zone]; D = [explicit legal/data answers]; E = [provider/model/data/spend].Even a completed decision packet does not authorize deployment, DNS changes, provider configuration, sending email, backup uploads, destructive restore/rollback, policy publication, participant outreach or AI spend. Those remain action-time gates.
camster91 commentedon Sep 5, 2026
RC1 governing-roadmap update — 2026-09-05
The only current release-critical code PR is #95, now ready for review at exact head
f8de3ee3180a455634a3261f82020675795e85fe.Evidence on that exact head:
CI Build / Build: zero-step infrastructure failure;Execution order remains:
mainSHA;No merge or external execution is authorized by this roadmap update.
camster91 commentedon Sep 6, 2026
Roadmap checkpoint: current
mainremainsb45170409543684a75579a13d7bdd6d8f8ffe8e8. The immediate RC1 code prerequisite, PR #95 exact head1f0877757c79e16ebdc0b91b68f1ecf8059449c3, is now ready for merge review: manual Codex review is clean, Ashbi Local CI and GitGuardian passed, and all inline findings are resolved. Sequence remains: separate merge decision for #95 → establish new exactmain→ run #29 disposable runtime/backup/restore evidence → continue #49/#60–#68 → #70 approval → #66 pilot. No #29 runtime execution or release-artifact freeze should occur against the pre-#95 main.