Skip to main content
This plan turns the owner’s decisions (ADRs 0075 to 0122, the package port plan and the 2026-10-19 questionnaire rounds) into an ordered, executable sequence. Its ordering rules are ADR 0123, which is Proposed.
This is a plan, not a commitment. Where it depends on a question the owner has not answered yet, it says assumed: <recommended default>, pending owner, and keys the question to the gap questionnaire (OR1, FO4, FW1 and so on). A changed answer re-orders only the waves that depend on it.
Stackra ships packages, and nothing deployable (0075). “Delivered” here means the package is merged, green, documented and publishable to npm.figentra.com. The reference services under services/ are test beds that prove the packages end to end.

How to read this page

  • Phases run in dependency order. Waves inside a phase are package-disjoint, so each wave can be split across agents with no shared files.
  • Source: Figentra OS, as-is or port + adapt or redesign ports from /Users/akouta/Projects/figentra/packages/os/<category>/<name> and is relicensed to MIT on port (0084). Medusa (MIT parts) ports only Medusa’s MIT paths, never its Enterprise paths. Fresh is written new.
  • Tier: every package in this table is free (@stackra/*, MIT). Pro work (@stackra-pro/*) lives in the private figentra/stackra-pro repository and is tracked as one track (0077).
  • Lane follows 0120: a new package is change risk R2 or higher, so it takes the full lane. A mechanical as-is port takes the lite lane (assumed: 0084 says only adapt, redesign and fresh rows need a spec; pending owner). Packages under packages/security/**, and the outbox and database packages, are R3: blocking security review and owner approval before merge.
  • Issue is the package’s Linear issue in team STA. Each package issue is a child of its wave issue, and its blocked-by relations mirror the “Depends on” column. Specs create the task issues later; this plan creates none.

Common definition of done

Every package row adds its own “Done when” line to this list.
1

The gate is green

pnpm verify passes on the merge commit: format, lint, typecheck, test, build, validate, boundaries and knip.
2

Tests prove it at the agreed floor

Tests sit in __tests__/ (0022). Coverage is 80% lines and functions and 70% branches; security, tenancy, iam, actions, outbox, workflow, versioning and validation reach 90/80 (assumed: TS3 a, pending owner). Integration tests use Testcontainers with Postgres, pgvector and ltree (assumed: TS4 a, pending owner).
3

It meets the port conventions

File-contract docblocks, one export per file, # subpath imports, no any, non-null assertions or enums, no Reflect metadata, and diagnostics coded STK (0084 decision 1). Entries follow the package layout (assumed: FW1 a, pending owner).
4

Drivers prove every deploy mode

A driver package ships a conformance suite. The suite runs in the air-gapped CI job once that job exists (spike STA-141), and the spec’s Impact section answers SaaS, on-prem and air-gapped (0076).
5

It is documented and releasable

A docs page, a changeset, and, for adapt, redesign and fresh rows, the package design ADR (0018). The Linear issue is Done with the PR attached.

Phases at a glance

Phase 0: SDLC and repo hygiene

Other agents own this phase right now; this plan only lists it so Phase 1 can wait for it. Nothing in Phase 1 starts until these land.

Phase 1: Foundation kernel

The kernel every other package imports. W1.1 has no workspace dependencies, so it can start the moment Phase 0 lands.

W1.1 · Kernel primitives (STA-52)

W1.2 · Container, config and logger (STA-53)

W1.3 · Validation, events core, storage, filesystem, i18n, devtools-kit (STA-54)

Phase 2: Data layer

@stackra/model stays client-safe; @stackra/database is the only package that imports MikroORM (0097). The migration spike (STA-137) must pass before database’s plan.

W2.1 · Model and traits (STA-55)

W2.2 · Database, locking and cache (STA-56)

Phase 3: Codegen and the generated app

Plain-TS services with no encore.* files; stackra gen emits the Encore app into the gitignored .stackra/encore (0090, 0091). The G3 spike passed 6/6 and the hot-reload spike measured about 0.6 s per edit; their constraints become requirements (export identity matching, explicit handler types, typed error mapping, build order, no encore build docker inside worktrees).

W3.1 · IR, console framework and app runtime (STA-57)

W3.2 · stackra gen and the stackra binary (STA-58)

W3.3 · Generated Encore app and reference services (STA-59)

Phase 4: Actions and messaging

Every operation is an action; a workflow sits behind it only when the criteria hit (0098, 0101). The eight messaging packages are fixed by 0078; events landed in W1.3 and notifications lands in W6.2.

W4.1 · Actions and outbox (STA-60)

W4.2 · Queue and scheduler (STA-61)

W4.3 · Workflow, webhooks, realtime and versioning (STA-62)

Phase 5: Security and tenancy

All R3. Claude runs these specs; nothing here is delegated (0066). The free tier is pool tenancy with RLS, RBAC behind check() and Better Auth core; the scope tree, DB-per-tenant and the Zanzibar engine are Pro drivers behind the same contracts (0088).

W5.2 · Identity and IAM (STA-64)

W5.3 · Connections store (STA-65)

Phase 6: Platform capabilities and AI

W6.1 · Registry, settings and feature flags (STA-66)

W6.2 · Notifications, search, media and analytics (STA-67)

The notifications spec is STA-35 (PR #14). Its clarify and plan run under the Phase 1 SDLC templates; its implementation waits for W6.1.

W6.3 · AI runtime (STA-68)

Phase 7: Client and experience

W7.1 depends only on the kernel, so a client agent can start it while the server phases run. The experience build order is X14: contracts, validator and evaluator, @stackra/ui parity and renderers; then dashboards; then the page and form builders (0112).

W7.1 · Client state, transport, query and brand (STA-69)

W7.2 · Router, navigation, ui parity, kbd and pwa (STA-70)

W7.3 · Experience runtime, content and forms (STA-71)

Track R: runway and distribution

Runs in parallel from now, in DP21 order (assumed: DP21 a, pending owner). Wave issue STA-72.

Track Pro

Wave issue STA-73, in figentra/stackra-pro, blocked by the npflared check (STA-29) and the HeroUI OEM answer (STA-41, OR9). Every item is a driver, module or extension behind a free contract, so none of it blocks a free wave: the scope tree and DB-per-tenant driver (after tenancy), the Zanzibar engine @stackra-pro/iam-relations (after iam), the entitlements engine, SSO, SCIM, phone sign-in and the OAuth provider (after identity), presence and co-editing (after realtime), Meilisearch and OpenSearch drivers (after search), the dashboard studio, page builder, form builder editors and experience blocks (after W7.3), @stackra-pro/ui, the admin resource kit, AI builder, registry UI and eval workspace (after ai), and the devtools UI.

Critical path

The longest chain decides the date of the first product slice. Everything else can run beside it. Critical path: Phase 0 → W1.1 → W1.2 → W1.3 → W2.1 → W2.2 → W3.2 → W4.1 → W5.1 → W5.2 → W6.1 → W6.2 → M5. The DP2 spike (STA-136) and the migration spike (STA-137) sit on it as gates, so run them first, before W1.1 finishes.

Parallel lanes and file ownership

At most five executors run at once, and each lane owns a disjoint set of paths (concurrent sessions). Shared files are serialized: catalogs in pnpm-workspace.yaml go through the dependency steward in one PR per wave, turbo.jsonc through the architecture guardian, and docs.json and the ADR index through the docs steward. On a conflict in a shared file, rebase and keep both sides’ entries.

Open decisions that block each phase

Keyed to the gap questionnaire. Each row states the default this plan assumes until the owner answers.

Spikes

Each spike is a Linear issue that blocks the package or wave it gates. Spikes run outside the repo (the existing ~/Projects/stackra-spike-gen sandbox) and end in a FINDINGS.md and an ADR amendment where the answer changes a decision. Already done: the Encore plus legacy-decorators spike (STA-6), the G3 generated-app spike (6/6) and the hot-reload spike.

Milestones

The first product slice (pending FO4)

Pending owner FO4. The plan assumes the questionnaire’s recommendation, FO4 a, because it is the smallest slice that exercises tenancy, iam, actions, the outbox, notifications, gen and deploy together. Option b (the notifications package alone) proves less; option c (Academorix’s first module) belongs in the Academorix repository.
Proposed slice, tracked in the “First product slice” project (STA-146):
  1. Sign up with Better Auth (email magic link and password) and create a tenant.
  2. Invite a member by email; the invite is a notification, and accepting it creates a membership.
  3. Role-gated CRUD on one resource, notes, through @Crud actions behind check().
  4. An email and an in-app notification when a note is shared.
  5. An audit trail of every action, written from events (an audit module in the reference app, per 0047).
  6. The same flows on the web console and the mobile app, deployed to staging.
Blocked by W5.2, W6.2, W7.2 and the DP2 spike.

Keeping this page true

The lead updates this page when a wave closes, a decision is answered or a spike reports. The Linear issues are the live state; this page is the order. A change to the ordering rules needs an amendment to ADR 0123.