Skip to main content

App Works — status tracker

Updated as work lands. Two independent axes per epic: spec and implementation.

  • Spec: — not started · Draft written · Reviewed · Approved
  • Impl: — not started · In progress · PR open · Merged · Verified (its ACCEPTANCE.md scenarios green on develop)

Last refreshed 2026-09-17, verified against develop @ 873274c9f (2026-09-17; previously e5f43f44d, authored against a655b53ca). No pull request exists for any epic yet. Jira tickets do not exist yet: every epic carries EW-TBD until the owner files the program epic and one story per epic (the newest id on 2026-09-17 was EW-816). The draft bodies to file are JIRA-DRAFT.md (current) and _build-artifacts/open-decisions/jira-tickets.md (the 2026-09-17 draft, kept unchanged). Jira assigns the keys: file the program epic first, then the thirteen stories, then replace every EW-TBD in the table below with the returned keys and keep the epic → story mapping. Never put a guessed number in this column.

Branch status 2026-09-19 (late) — the implementation work lives on feat/app-works-implementation (HEAD c6ee9d899, 342 commits ahead of its base plan/any-repo-as-work @ a183ecd70), pushed and not merged: no pull request exists, deliberately — the owner reviews the branch first.

Where the programme stands. The Impl column reads In progress for all thirteen epics. The task-path meter (tools/verify-task-paths.mjs) puts 1 634 root-anchored paths in the repository, 244 paths a task marks as its own (up from 186), and 161 of 699 task headings with landed surface — 23.0 % of tasks and 25.8 % of the 947 paths tasks promise to create. Thinnest: APW-08 (1 task), APW-10 (3), APW-09 (4) and APW-04 (5); thickest: APW-06 (27), APW-13 (24), APW-11 (21) and APW-07 (20). Every epic's Notes cell carries its landed task ids, and the ledger docs/internal/app-works-build-progress.md is the authority for what each landing proved: §3 is the per-epic table (refreshed from the meter, so it is reproducible with one command), §5 the routed-findings register (spec drift D1–D19, code findings C1–C34, with C14/C16/C18/C19/C22/C23/C27 now closed and C32–C34 opened by a lane) and §6 the dated log.

⚠️ Two metering caveats worth reading before quoting those numbers. The meter counts a path as landed only when a task text marks it new, so a slice can ship ten files and register none of them (APW-03 T17 did exactly that, which is why an epic's named count can fall while its landed rises). And it decides "exists" from git ls-files, so nothing counts until it is committed.

⚠️ Landed is not wired, and bound is not reachable (2026-09-26). Every App Works collaborator is @Optional(), so a token the declaring module cannot reach does not crash anything: the feature behind it silently answers "unavailable". The dormancy register (packages/agent/src/app-runtime/__tests__/app-works-port-dormancy.spec.ts) counts a token BOUND when some module's metadata provides it, which is not the same question, and e23c2f844 found AppEnvModule imported by no API module while its tokens read BOUND (no App Build could ever be deployable). The question "can Nest actually resolve it in the graph that ships" is asked by apps/api/src/app-works-di-reachability.spec.ts (3a956180e): it walks the API root and the App Works worker contexts with SWC-compiled metadata, and keeps its allow-lists exact in both directions. Its OPEN_API_GAPS (DeployFacadeService's AppDomainsService) and OPEN_WORKER_GAPS (13 APW-06 T71 worker bindings, an owner decision) are the known gaps; read its "What the walker does not see" before treating a green run as "all wired".

APW-13's P0 is complete, which is what the other epics' PR lanes were waiting for (R-38): the fake GitHub (43 recorded fixtures), the helpers and their specs, vitest.e2e-harness.config.ts (T4), the acceptance config and its setup (T12), the five regression lanes (T14–T18), the harness unit lane and the operator runbook (T56). The lanes have been run repeatedly against a live local stack — fake GitHub, a real API on in-memory SQLite, a prod-built web — and the suite keeps growing: the harness lane is now 232 tests, the App Works lane specs run green at --workers=1, and the armed register-work lanes are 26 passed exit 0 since C14 was fixed (the fake had been answering GET /user 200 for every token, which made the intended credential gate unreachable and every such assertion unfalsifiable). In CI (.github/workflows/e2e.yml, 33 shards) a run is queued on 6dcfa473b — the first pin in this programme's history to carry BOTH React-Server-Component crash fixes (C22 on the create page, C27 on the Work detail page); the earlier shard reds were the API-boot defect (46fe5ac19) and then that crash class itself. ci.yml on the previous tip finished 14 of 15 jobs green with exactly one red — run test on all packages = C16, proven pre-existing by a base-commit worktree run and already fixed upstream on origin/develop (08044d343; this branch is 189 commits behind develop, 342 ahead of its base).

The acceptance lanes have still never run end to end against a Blueprint (they need the nightly lane and an estate with cluster access), so "23.0 % landed" is a measure of code in the repository, not of proven behaviour. What is proven against a live stack keeps growing: APW-01's inspect route boots and answers (401 unauthenticated, 404 on a wrong path, 0 DI failures); APW-05's app-build-prepare runner really executes over the internal RPC hop (201 {"status":"skipped","reason":"workUnavailable",…}); the Work detail page renders, with C27's fix proven by a request-time A/B (digest: '2265010250' 3× before / 0× after in the web server's own log); and all four of APW-12's sign-in methods are green against a real fake provider. Three of the batch's findings exist only because a lane was run: C32 — nothing calls AppSpecService.initialize, so no App spec state row can exist and the page is a 404 for every Work; C33 — a viewer is locked out of the whole Settings area, contradicting FR-76's "a viewer can read the App spec"; and C34 — the App spec poll route answered an empty 500 instead of the house 400 when a caller omitted the browser's workspace selector (fixed; the poll itself was never broken).

IDEpicWaveSpecImplJiraBranch / PRNotes
APW-01App Work kind & create from any repository URL1DraftIn progressEW-TBD—Needs APW-03 P2, APW-06 T2–T3 and APW-13 P0 first (R-38) Implementation status 2026-09-18 on feat/app-works-implementation: T1/T3/T7/T7b (the app kind, its capabilities, the instance setting in API + manifests) and T20 (the fail-closed chip) are landed and verified; T2's contracts (packages/contracts/src/apps/app-source.ts) landed with the shared contracts surface.
APW-02Fork lifecycle0 · 1DraftIn progressEW-TBD—P0 (checkout keys, fork readiness) unblocks APW-01 Implementation status 2026-09-18 on feat/app-works-implementation: Wave 0 P0 (checkout keys, fork readiness) and T9/T10 (fork capabilities), T12–T14 (WorkUpstreamState entity, migration, repository), T15/T16 (AppWorksModule, GitHub errors, the nine repository facts), T17/T18 (findExistingFork, sync, divergence, branch refs), T19–T21 (repository copy, Actions permissions, webhooks) and T23 (AppUpstreamStateService + the ready-handler port) are landed and verified; T22/T24/T25 are in flight. Round 2026-09-18: T22 (the fork facade methods with the materialise-then-call guard), T25 (AppActionsHygieneService) and T24 (AppForkReadinessService) landed — 93 tests; three task-vs-plan disagreements recorded and resolved toward the plan.
APW-03App spec, Apps catalog, license gate1 · 2 · 3DraftIn progressEW-TBD—Needs ever-works/templates (the listing repository, created 2026-09-17) — the earlier drafts called it ever-works/apps (R-29) Implementation status 2026-09-18 on feat/app-works-implementation: T1 (spec contracts), T3 (the structural appSpecSchema and the regenerated §8 JSON Schema), T4/T5 (the §21 reference grammar and R1–R27), T6 (positioned issues + the public validator) and T7/T8 (kind: app routed to the validator, the stand-alone App spec schema and its route) are landed and verified; T9–T11 are in flight. Round 2026-09-18: T9/T10/T11 landed — the WorkAppSpecState entity (55 columns, three indexes), its migration and the state repository — 100 + 17 tests; four plan-vs-reality findings recorded (UPDATE … RETURNING is not available off Postgres, the coalescing predicate contradicts the contract, timestamptz vs PortableDateColumn, and migration:generate cannot run in this checkout).
APW-04App Provisioner1DraftIn progressEW-TBD—Implementation status 2026-09-18 on feat/app-works-implementation: T1 landed (d5e75f60b) — the enforcesRuntimeNetworking flag, runSandboxSession() and the sandbox session types on the pipeline-plugin contract (+88/0) plus the claude-managed-agent implementation (+308/0), independently certified (five perturbations and a compile pin, every restore byte-identical); that plugin 10 files / 98 tests, the contract package 35 files / 517 tests, both type-checks exit 0. The epic's other 59 tasks are unstarted.
APW-05Builds1 · 3DraftIn progressEW-TBD—PR-lane specs run in the APW-13 P0 harness (R-38) Implementation status 2026-09-18 on feat/app-works-implementation: only T1's contract module (packages/contracts/src/apps/builds.ts) has landed, with the shared contracts surface — no build service, runner or lane exists yet.
APW-06App runtime on Kubernetes1–3DraftIn progressEW-TBD—Managed target stays off until APW-10 gate Implementation status 2026-09-18 on feat/app-works-implementation: T1–T14 (the runtime contracts, the plugin App-deployment contract, the agent ports and their fail-closed bindings, the k8s names/security/manifest/network-policy renderers, the runner script, the job renderer, the rollout classifier, the kubeconfig guard, the deployer phase machine and the status/scale/logs/destroy reader), T20 (the runtime facade and the worker-context gate), T58 (App Work deletion) and T60 (verification targets) are landed and verified; T19/T21 are in flight. Round 2026-09-18: T19 (the everWorks.apps getters incl. the §8.3 apex rule and the §6.1 allowlist) and T21 (the deploy preconditions + the license gate) landed — 476 tests; every unbound seam documented and tested (managed fails closed, your-cluster warns).
APW-07App env & dependencies1 · 2DraftIn progressEW-TBD—P1a (contracts, entities, providers) lands with the foundations; P1b needs APW-01/APW-06 (R-38) Implementation status 2026-09-18 on feat/app-works-implementation: T1/T2 (the env and dependency contracts), T3 (the app-dependency capability and its category plus the two total web maps it forces), T5–T8 (both tables, their migrations and repositories), T9–T11 (the enc::v1:: envelope, the five generators on node:crypto, the re2js pattern validator), T12 (the .env import parser, 37 tests, 8 perturbations) and T16 (the dependency facade and service) are landed and verified; T13 (AppEnvService) is in flight. Round 2026-09-18: T13 (AppEnvService, 281 tests in the epic selection) and T17 (the provision dispatcher, the job and APW07-G24’s propagate shape — 53 + 571 tests) landed, together with APW07-G28 (the port-vs-card reason vocabulary, which had been dropping a failed card’s reason entirely) and APW07-G29 (the 50 ms pattern budget measured at the engine’s throughput edge: 61.96 ms for the adversarial pattern vs 43.33 ms for a flat one at 65,536 bytes — the plan’s three options are recorded).
APW-08Evolve loop0 · 1DraftIn progressEW-TBD—P0 = agent git tool fix (independent PR). The audit round added FR-69…FR-76, S32…S36, ACC-08-33…ACC-08-47 and T47–T56 (tool policy, Fleet containment admission, operator switches, checks backfill/notification, accessibility, size limits, keyed thread posts, follow-up key, cost rollup); P1 therefore carries ACC-08-01…ACC-08-47 Implementation status 2026-09-18 on feat/app-works-implementation: Wave 0 P0 (the agent git tools fix) has landed and is verified; the evolve loop itself has not started.
APW-09Upstream pull requests1 · 2DraftIn progressEW-TBD—Its own spec puts P1 in Wave 1 and P2–P3 in Wave 2; the earlier cell read 2 alone Implementation status 2026-09-18 on feat/app-works-implementation: T1/T2 (cross-repo PR fields, the two review reads, the interaction limit, and the provisional facade seam retired as an alias) and T4 (the facade pass-throughs and the member token) are landed and verified.
APW-10Ever Works Apps hosting tier (launch gate)2 · 3DraftIn progressEW-TBD—Infra specifics in the private operations repository Implementation status 2026-09-18 on feat/app-works-implementation: only T1's contract module (packages/contracts/src/apps/apps-tier.ts) has landed, with the shared contracts surface — no hosting tier, policy or managed target exists yet.
APW-11App Launcher & Apps registry API1 · 3DraftIn progressEW-TBD—Reads ever-works/platforms (exists 2026-09-17). The audit round added FR-55…FR-66, S23…S26, ACC-11-41…ACC-11-54 and T31–T33 (operator switch in the three deploy manifests, app_launcher Activity badge/i18n, non-production seed route) plus drafted catalog content in APW-11-app-launcher/catalog-draft/. Two owner items remain: the visibility/token of ever-works/platforms (R-29 — private at creation, while the reader fetches over the raw host) and the Wave 3 extraction repository + npm scope (EXT-30/CL-48). Implementation status 2026-09-18 on feat/app-works-implementation: T1 (contracts), T2–T5 (entity, migration, repositories), T6 (AppLauncherService), T7 (exposure on Work update), T8 (platform catalog service), T9 (routes, guard, module + its config half — one accessor read by the guard and by features.appLauncherEnabled), T21 (the no-sign-on copy guard), T30 (R-25 classification), T31 (the operator switches in all three manifests) and T32 (the app_launcher badge in 21 locales) are landed and verified; T20 (P1 e2e) and T33 (the non-production seed route) are in flight. Updated 2026-09-18: T33's two files (apps/api/src/app-launcher/e2e-seed.controller.ts and its spec) are in the repository, which the task-path meter reports as landed surface; T20's P1 e2e remains in flight. APW-11's landed count is now 43 paths, the largest of the thirteen epics. R-29 is still open and now measured twice: ever-works/platforms is private and the anonymous raw-host read returns 404, so the launcher's production catalog read cannot work until the visibility or the read path is decided (the public ever-works/templates returns 200 as the control).
APW-12Ever ID2 · 3DraftIn progressEW-TBD—Cross-repository (Ever Works, Teams, Gauzy) Implementation status 2026-10-01 on develop: the Ever Works relying party (P1) is wired — the external_identities table and the two session columns, the identity provider facade with the administrator's on/off switch, the /api/auth/ever-id/* routes (sign-in, the S2 confirmation, connect and disconnect, back-channel logout with a jti cache, terminal device sign-in, the delegated apps:read read, Test connection), the web sign-in button behind the ever-id flag, the Settings card, the sign-out dialog and the CLI/node device sign-in. It ships turned OFF: nothing changes until a platform administrator turns it on. Stage verification against the real provider is next.
APW-13Golden paths & acceptance suite0 · 1 · 2DraftIn progressEW-TBD—Implementation status 2026-09-18 on feat/app-works-implementation: the P0 harness is written but UNCOMMITTED — fake GitHub (43 recorded fixtures), the canary sink, k8s assertions, the live/poll/evidence helpers and the EVER_WORKS_E2E_FAKES switch (382 plugin tests, 0 type errors, additions only on every shared file); playwright.app-works.config.ts (T12) and the lanes themselves are still to come. No acceptance lane has ever run against the 549 acceptance ids.

Merge order​

  1. Wave 0 (independent, small): APW-08 P0 (agent git tools) · APW-02 P0 (checkout keys, fork readiness) · APW-13 P0 (the test harness other epics' PR-lane specs run against: fake GitHub, the EVER_WORKS_E2E_FAKES non-production switch, helpers, playwright.app-works.config.ts — see APW-13/plan.md §12).
  2. Wave 1 foundations (parallel): APW-03 P1 · APW-02 P1 · APW-07 P1a · APW-11 P1 · APW-09 P1 (its own spec and ACCEPTANCE both place APW-09 P1 in Wave 1; this row previously omitted it — see the note below).
  3. Wave 1 prerequisites for creation: APW-03 P2 (T22 commitFiles, T26 resolver + AppSourceCatalogAdapter, T28 apply job, T32 AppsCatalogBrowser — the pieces APW-01 P1 compiles against) · APW-06 T2–T3 (packages/agent/src/app-runtime/ports.ts and APPS_TIER_POLICY, which APW-01 T12–T14 inject). These are small dependency PRs, not whole phases; they land before APW-01 P1 because APW-01 cannot build without them.
  4. Wave 1 creation and running: APW-01 P1 → APW-05 P1 → APW-06 P1 → APW-04 P1.
  5. Wave 1 loop: APW-08 P1 → APW-13 P1 (the owner's example green on a user cluster).
  6. Wave 2: APW-10 P1–P2 → APW-06 P2 · APW-07 P1b (controllers, web, live acceptance) and APW-07 P2 → APW-09 P2 · APW-09 P3 (both are Wave 2 per APW-09/spec.md and its plan §11 — P1 is the Wave 1 half, already in step 2) · APW-12 P1 → APW-13 P2.
  7. Wave 3: APW-05 P3 · APW-06 P3 · APW-10 P3 · APW-11 P2 · APW-12 P2–P3.

Revised 2026-09-17 (resolution R-38): the previous step 2 read "APW-03 P1 · APW-02 P1 · APW-07 P1 · APW-11 P1 · APW-09 P1", step 3 read "APW-01 P1 → APW-05 P1 → APW-06 P1 → APW-04 P1" and step 1 read "APW-08 P0 · APW-02 P0". APW-13 P0 and the APW-03 P2 / APW-06 T2–T3 prerequisites were missing from every step, and APW-07 P1 was placed before two of the epics its P1 needs; the order above adds them and moves nothing backwards, so no epic that was already mergeable becomes blocked. The dependency columns in README §5 and each epic's own Depends on line are the other half of this rule — an epic's own spec wins over the table.

Two ordering issues to settle before Wave 1 starts (both discovered 2026-09-17; neither blocks Wave 0):

  • APW-06 ↔ APW-07 declare each other. APW-06/spec.md:14 depends on APW-07 ("env values, App dependencies") and APW-07/spec.md:13-14 depends on APW-06 ("deploy target, cluster access, domains"). The merge order above lands APW-07 P1a first, so one direction must be softened. Recommended: APW-07 owns the env/dependency contracts and lands first; APW-06 consumes them — and APW-07's stated dependency on APW-06 becomes a dependency on APW-06's ports/interfaces only, which APW-07 defines against in P1a. The half of APW-07 P1 that genuinely needs APW-06 (controllers, web, live acceptance) is P1b and lands after APW-06 P1: the phase split is recorded in APW-07/tasks.md.
  • README's dependency column was corrected on 2026-09-17 to match each epic's own Depends on line (APW-04 +07, APW-05 +02/+07, APW-06 +10, APW-08 +03, APW-11 +12). Keep the two in step: an epic's own spec wins.

Spec status criteria (what Reviewed and Approved mean)​

The Spec column's Reviewed and Approved states are earned against a repeatable checklist, not a reading: checklists/requirements.md is that checklist, run per epic at its recorded baseline commit.

  • Reviewed — every item in checklists/requirements.md ticked by a second reviewer, with the unresolved items listed in the epic's own plan.md "known gaps" section rather than silently absorbed.
  • Approved — Reviewed, plus the owner's sign-off and, for a wave, no open blocking [NEEDS CLARIFICATION] marker for that wave (CLARIFICATIONS.md carries one row per marker with the wave it blocks; a marker whose default the specs already assume may be default accepted and does not block).
  • The mechanical half of Reviewed is node docs/specs/features/app-works/tools/verify-spec-tree.mjs (links resolve, every ACC id is defined by an epic and indexed in ACCEPTANCE) — it is necessary and not sufficient.

Owner and operator actions the epics cannot take​

These are tracked here because no epic owns them; each is a prerequisite for the wave named.

  • APW-12 P0 — Ever ID provider. Owner decisions recorded 2026-09-17 (provider ZITADEL, self-hosted as-is, one instance for every platform at auth.ever.co — resolution R-28); the operator then stands the provider up in three environments, registers the clients, scopes, audiences and back-channel logout URIs of APW-12/idp-options.md §6.1, and records the development Test connection run (APW-12 T2 + T47).
  • GitHub App registrations per environment (EXT-15). Before APW-02 P1 and APW-05 P1 merge, the owner updates the Ever Works GitHub App in dev, stage and production with the permissions and events of GITHUB-PERMISSIONS.md, notifies every installation owner, and plans the re-approval GitHub requires from each of them when permissions grow — until an installation owner accepts, calls fail with 403 and the APW-02 permission-missing message is what users see. The APW-02 T42 contract probe is the confirmation.
  • Legal review (EXT-19). README D13 makes the licence registry legal-reviewed before launch and APW-03/catalog.md §7 rule 3 enforces a named reviewer through ever-works/apps CODEOWNERS, with amber entries requiring a filed upstream agreement. The owner names the legal reviewers and the GitHub team used in CODEOWNERS, commissions the review of licenses.yml and the policy drafts, and records outcomes and agreements in the private operations repository. Until then the registry ships marked "draft — legal review required" and no amber entry is published.
  • Test estate (EXT-04). The organizations, machine user, long-lived repositories, test cluster(s), DNS zone, mail and canary sinks, and the app-works-dev / app-works-stage GitHub environments of ACCEPTANCE §0.3–§0.4 are owner actions (APW-13 T20/T21); addresses live only in the private operations repository.

Migration timestamp blocks​

1792 + two-digit epic + two-digit slot + 00000 (see README §7 rule 6; stamping rule: Resolution R-39). Newest migration on develop when authored: 1791200100000-CreateOnboardingChecklists.ts; on ee45946e5 (re-verified 2026-09-17): 1791240000000-AddSafetyRailsCore.ts; re-checked against 873274c9f (2026-09-17, 21 commits later): unchanged, so every reserved 1792… timestamp is still above it. AW-24 P2 has reserved 1791240100000-AddHeldActionExecution.ts, also below the block.

Stamp in merge order, not authoring order (R-39). The merge order above is the sequence the values must follow: a migration that lands later sorts above one that landed earlier inside its own epic's slot, and the two-digit slot is chosen so that the epic order in the merge order is monotonic. The audit's concrete finding was that APW-11 P1 (1792110000000) and APW-07 P1 (1792070000000) were scheduled before APW-01/05/06 (1792 01…, 1792 05…, 1792 06…), which would have forced those epics to re-stamp out of their blocks; the revised order in this file removes that inversion, and any future reordering re-checks this section. A contract test reserves the 1792 prefix for App Works filenames and reports a foreign file inside the block, so unrelated develop work cannot take a value here unnoticed.