App Works — clarification register
Program: App Works (app-works) · Status: Draft · Created: 2026-09-17
Authored against: origin/develop @ a655b53ca · Verified against: develop @ 873274c9f
(2026-09-17, per README :6)
Register recount and every citation below re-verified: on feat/app-works-implementation, 2026-09-17, from
the worktree. Several agents edit this tree concurrently, so line numbers move between reads — §5 gives the
one-line command that re-derives both the count and the lines.
Companion documents: README.md (§2 decisions D1–D15, §4 waves, §7 rules, §8 owner questions) ·
CONTRACTS.md (§0 Resolutions R-1…R-39, binding) · ACCEPTANCE.md ·
TRACKER.md (status, and §"Spec status criteria" :65-79) · BUILD-READINESS.md ·
checklists/requirements.md
.specify/templates/spec-template.md:86-91 says a [NEEDS CLARIFICATION: …] marker blocks approval, and
every epic's §9 uses that form. Until this file existed, no artifact answered which markers were still open,
which were already settled by a binding Resolution in CONTRACTS.md §0
or by a decision in README §2, and which were simply the spec's own default that
nobody had written down. This is that register. It is additive: it removes no marker, resolves no epic text
by itself, and proposes no new Resolution id.
0. How to read this register
| Column | Meaning |
|---|---|
| Id | CL-nn, stable and flat across the program. Cite it as "clarification CL-nn". A row is never renumbered and never deleted; a row that is decided keeps its id and gains a status. |
| Epic | The epic whose §9 carries the marker. |
| Question (spec) | The marker, tightly paraphrased, with the spec.md line range that carries it. Open the file to read it verbatim — no paraphrase is normative. |
| Default the spec assumes | What the epic already does or assumes today. Blank means the spec states no default, which is the strongest reason to decide the row. |
| Blocks | The wave and phase whose approval the marker gates, from the epic's own **Program**: header and, where the marker names a wave, from the marker itself. A marker in a later wave does not block an earlier one. |
| Decides | Who can answer it: owner (product/commercial), legal, security, engineering (a verification or design call the epic can make itself). |
| Status | open · resolved-by R-n (a binding CONTRACTS §0 resolution settles it) · default accepted (the spec's own default, or a decision record's recommended default, is the answer and nothing contradicts it). |
| Decision date | The date the decision was made. — while a row is open, and on a default accepted row until the marker is converted in place, at which point the converting PR stamps the date. |
Three conversions are available for every row, and none of them deletes anything (owner rule, 2026-09-17,
Resolution R-26):
resolved-by R-n— the marker's question is already answered by a binding Resolution. The marker keeps its text and gains a**Resolved (R-n, CONTRACTS §0):**line underneath, which is the form APW-09-upstream-pull-requests/spec.md:731and APW-08-evolve-loop/spec.md:784,792now use.default accepted— the epic states a_Default:_, a decision record states the recommended default, or an existing code path fixes it. Same form: the marker stays, the answer is added.open— the row needs a person. It keeps its marker until it is answered, and the answer is then written in place and the row here flips.
The epics already demonstrate the convention, in four house forms:
APW-02 :625,627 (## 9. Open questions then - **Resolved (Resolution R-21): …**),
APW-03 :739-752 (## 9 → "Resolved by the program audit" → "Still open"),
APW-06 :799,805,809 (Resolved (CONTRACTS C2)),
APW-07 :640,642,644 (Resolved (CONTRACTS R-11) and a
schema/rule citation), APW-10 :614-624 ("Resolved by the program audit
(2026-09-17)" then "Still open") and :628 ([ANSWERED 2026-09-17 — which apex domain?]),
APW-11 :687-700, whose §9 preamble names this register and which carries the
first inline conversion (:698), and APW-12 :588 (a struck-through marker
carrying its own answer).
1. The register — 65 open markers
Counted by grepping every docs/specs/features/app-works/APW-*/spec.md for the literal string
NEEDS CLARIFICATION. The recount and its reconciliation with the artifacts that quote other numbers are in
§5. No marker lives in any plan.md or tasks.md — the string appears only in spec.md files and in the
audit artifacts.
| Id | Epic | Question (spec) | Default the spec assumes | Blocks | Decides | Status | Decision date |
|---|---|---|---|---|---|---|---|
| CL-01 | APW-01 | Private copy of a private upstream whose owner disallows forking — refuse it? (APW-01-app-work-kind/spec.md:759-760) | Refuse, to respect the upstream owner's intent | Wave 1 · P1 | owner | open | — |
| CL-02 | APW-01 | Should Link on a repository another account already uses become "join as member"? (spec.md:761-762) | No — keep the existing conflict with instructions to ask the owner; a join-request flow is a separate epic | Wave 1 · P1 | owner | open | — |
| CL-03 | APW-01 | Refuse a Repository Work created after an App Work on the same repository? (spec.md:763-764) | No refusal — the Repository Work create path is unchanged (program rule 1) | Wave 1 · P1 | owner | open | — |
| CL-04 | APW-01 | Private-copy size ceiling (500 MB) and whether a member names the fork at creation (spec.md:765-766) | 500 MB, to keep a copy inside one job budget; raise it once copies run on APW-10's in-cluster builder; fork named by the platform | Wave 1 · P1 (ceiling re-opens Wave 3) | owner + engineering | open | — |
| CL-05 | APW-02 | Merge a clean diverged upstream sync directly, instead of always opening a pull request? (APW-02-fork-lifecycle/spec.md:630-631) | Always open a pull request, so builds and deploys follow review; an opt-in switch is the alternative | Wave 1 · P1 (upstream sync) | owner | open | — |
| CL-06 | APW-02 | Minimum upstream-sync schedule — is hourly the floor, and is it lower for paying accounts? (spec.md:632-633) | Hourly is the floor, to protect the member's API budget | Wave 1 · P1 | owner | open | — |
| CL-07 | APW-02 | Offer Actions hygiene on linked repositories too? (spec.md:634) | Off — those are the member's own workflows | Wave 1 · P1 | owner | open | — |
| CL-65 | APW-02 | Must an upstream update be reviewed before it goes live? A fast-forward lands upstream's commits on the tracked branch, APW-05 builds that push and APW-06 deploys it, so a compromised release can be live within one sync tick with no human in the loop (spec.md:635-643) | The default stays as specified: there is no per-App-Work Upstream updates setting yet, and nothing auto-deploys an unreviewed upstream change that touches automation. FR-60/FR-61 already hold automatic syncs whenever the incoming range touches workflows | Wave 1 · P1 | owner | open — added by the 2026-09-17 audit; registered as a new id, appended without renumbering | — |
| CL-08 | APW-03 | Is Cal.diy meant to be a Wave 2 Ever Works Apps demo, or a Your cluster flagship only? (APW-03-app-spec-and-catalog/spec.md:754-756; README §8 question 10 restates the same subject) | The example catalog entry sets managed hosting to "not offered"; the upstream recommends personal, non-production use | Wave 2 (Ever Works Apps) | owner + legal | open | — |
| CL-09 | APW-03 | Is a bundled license-registry snapshot acceptable as an outage fallback? (spec.md:757-759) | Yes — ship a snapshot as an outage fallback only, mirroring the Work Blueprints built-in list | Wave 1 · P1 | engineering | open | — |
| CL-10 | APW-03 | Is a per-entry upstream-agreement reference enough, or must an agreement be scoped to specific versions? (spec.md:760-766) | Record only a reference in the catalog entry (legal-reviewed); the agreement itself lives in the private operations repository | Wave 2 (amber on Ever Works Apps) | legal | open — narrowed by R-3 | — |
| CL-11 | APW-04 | Which sandbox is the Wave 1 provisioning runtime, and may an owner's own fleet node be allowed with an explicit "this machine's network is not restricted" consent? (APW-04-app-provisioner/spec.md:663-665) | The sole runtime that enforces restricted networking today | Wave 1 · P1 | owner + security | open | — |
| CL-12 | APW-04 | Keep web access off entirely, or allow read-only fetches from the repository's declared homepage domain? (spec.md:666-667) | Web access off — repository only | Wave 1 · P1 | security | open | — |
| CL-13 | APW-04 | Is a new "ready for review" git-provider capability worth adding, to open the provisioning PR as a draft until verified? (spec.md:668-669) | No — the Task state is enough | Wave 1 · P1 | engineering | open | — |
| CL-14 | APW-04 | Are 3,000,000 tokens and 240 runner minutes the right defaults for a first provisioning of a large monorepo? (spec.md:670-671) | Those values | Wave 1 · P1 | owner | open | — |
| CL-15 | APW-04 | Which license does an App spec suggested by the Provisioner carry in the catalog? (spec.md:672) | Not stated | Wave 1 · P1 | legal (+ APW-03) | open | — |
| CL-16 | APW-05 | May the zero-config auto strategy build on GitHub-hosted runners? (APW-05-builds/spec.md:694-696) | No. Wave 1 refuses it: the App Provisioner writes a Dockerfile instead, and auto stays refused until a build provider supports it (R-13) | Wave 1 · P1 | engineering + owner | open — shaped by R-13 | — |
| CL-17 | APW-05 | Default package visibility for a first push from a public repository's workflow (spec.md:697-703) | Must be verified against GitHub before P1 ships; the pull-token flow covers both, but the Builds-tab copy depends on the answer | Wave 1 · P1 | engineering | open (a verification, not a debate) | — |
| CL-18 | APW-05 | Larger runners for private copies (spec.md:704-705) | A label the owner configures, with its memory; no guided setup in P1 | Wave 1 · P1 | engineering | open | — |
| CL-19 | APW-05 | Always propose the build workflow as a pull request? (spec.md:706-707) | No — direct commit per FR-7 (about two minutes sooner on repositories the App Work created); a per-App-Work switch later | Wave 1 · P1 | owner | resolved-by R-4 | 2026-09-17 |
| CL-20 | APW-05 | Critical vulnerabilities on the managed tier — block deploys, and may the owner override in Wave 3? (spec.md:708-709) | Block deploys of images with a fixable critical finding; no owner override in Wave 3 | Wave 3 · P3 | security + owner | open | — |
| CL-21 | APW-05 | Build-minute caps for ordinary pushes (spec.md:710-711) | No cap on pushes in P1; the receipt makes the spend visible | Wave 1 · P1 | owner | open — the answer is shaped by R-31's cap table | — |
| CL-22 | APW-06 | Is an outbound connector (an agent installed in the cluster that dials Ever Works) wanted in a later wave, for clusters on private addresses? (APW-06-app-runtime/spec.md:801-806) | No; documented, with an operator allow-list as the route for self-hosted installations | Wave 2–3 | owner + engineering | open | — |
| CL-23 | APW-06 | Custom domains on Ever Works Apps — Wave 2 or Wave 3? (spec.md:807-808) | Managed subdomain only in Wave 2; custom domains in Wave 3, because they depend on APW-10's certificate mechanism | Wave 2 · P2 → Wave 3 | owner + engineering | open — consistent with R-16 | — |
| CL-24 | APW-06 | What happens to kept volumes and dependencies after an App Work is deleted? (spec.md:811-813) | They stay on the owner's cluster; Activity names them and the owner removes them by hand; generated values protecting that data are deleted with the App Work, and the dialog says so | Wave 1–2 | engineering | default accepted — R-15 governs | — |
| CL-25 | APW-06 | Is auto-deploy on by default on the managed tier, where Deployments spend compute? (spec.md:814-815) | On, with the receipt in Activity | Wave 2 · P2 | owner | open — the switch is R-30's EVER_WORKS_APP_AUTO_DEPLOY_ENABLED either way | — |
| CL-26 | APW-06 | Is a 60-second health poll per user cluster (1 440 calls/day) acceptable to owners who pay for API calls on hosted control planes? (spec.md:816-817) | Yes; configurable later | Wave 1 · P1 | engineering + owner | open | — |
| CL-27 | APW-07 | Which S3-compatible server ships in the cluster? (APW-07-app-env-and-dependencies/spec.md:647-649) | The provider's image is an operator-pinned setting; the platform ships a tested default and documents alternatives | Wave 1 · P1 | engineering | open | — |
| CL-28 | APW-07 | Browser-reachable object storage for apps that hand out upload links (spec.md:650-652) | Wave 1 in-cluster storage is internal only; apps needing browser uploads use the owner's own S3 | Wave 1 · P1 | owner | open | — |
| CL-29 | APW-07 | Kept data after an App Work is deleted (Wave 1) (spec.md:653-655) | Activity lists released in-cluster dependencies by name and the owner removes them by hand | Wave 1 · P1 | engineering | default accepted — R-15 governs | — |
| CL-30 | APW-07 | Kept managed data after an App Work is deleted (Wave 2) — kept until deleted, or deleted on a timer? (spec.md:656-658) | Kept until the owner deletes it; storage beyond 30 days after deletion is billed | Wave 2 · P2 | owner + legal | open | — |
| CL-31 | APW-07 | Should generated values be exportable for an owner leaving the platform? (spec.md:659-661) | None in Wave 1; there is no reveal by design, and the values remain in the app's secret on the owner's own cluster | Wave 1 · P1 | security + owner | open | — |
| CL-32 | APW-07 | Is a 60-second statement timeout on the managed tier right? (spec.md:662-664) | 60 seconds for the role; migration jobs set their own session timeout, up to 15 minutes | Wave 2 · P2 | engineering | open | — |
| CL-33 | APW-08 | Does "Live with warnings" close the Task? (APW-08-evolve-loop/spec.md:774-776) | Closed here — the app runs and APW-06 did not roll back — with a manual fix Task offered | Wave 1 · P1 | owner | default accepted (the spec already states the answer; confirmation still welcome) — aliased CL-08-1 in spec.md §9 | — |
| CL-34 | APW-08 | Are .github/workflows/** protected by default? (spec.md:777-780) | Protected — it blocks CI changes an owner might want an Agent to make; an App spec opt-out could follow | Wave 1 · P1 | owner + security | open — aliased CL-08-2 in spec.md §9 | — |
| CL-35 | APW-08 | CI checks and "a red check opens no pull request": open cloud runs as pull requests, or open drafts until green? (spec.md:781-783) | Cloud runs open a pull request and the gate governs merge-readiness and the fix loop; Fleet runs keep "red opens nothing" | Wave 1 · P1 | engineering | decided in place — R-9 (converted at spec.md:784; aliased CL-08-3 there) | 2026-09-17 |
| CL-36 | APW-08 | Default change Agent — the FR-42 rule, or an explicit per-App-Work "Agent for changes" setting? (spec.md:789-791) | The last Agent that worked on the Work, then the only pinned or assigned Agent | Wave 1 · P1 | engineering | decided in place — R-21 (converted at spec.md:792; aliased CL-08-4 there) | 2026-09-17 |
| CL-37 | APW-08 | Follow-up budget — 2 per change / 3 open per Work, or tied to a monthly budget instead? (spec.md:796-797) | 2 per change / 3 open per Work | Wave 1 · P1 | owner | open — aliased CL-08-5 in spec.md §9 | — |
| CL-38 | APW-09 | Should the approval also show a "Checked the contribution guide for AI policy" line with the quoted evidence either way? (APW-09-upstream-pull-requests/spec.md:716-718) | The Agent reads the guide and quotes the sentence; a false positive only refuses, a false negative sends a pull request the project did not want | Wave 2 · P2 | owner | open | — |
| CL-39 | APW-09 | Daily limit numbers — 1 per project per day and 3 overall, or per-plan limits? (spec.md:723-724) | 1 per project per day, 3 overall; per-plan limits would be additive | Wave 2 · P2 | owner | open — R-31 supplies the cap mechanism | — |
| CL-40 | APW-09 | Upstream tab ownership — "whichever epic ships first creates the tab" (spec.md:729-730) | One tab, two sections: APW-02 shows sync status, APW-09 the pull requests | Wave 1 · P1 | engineering | decided in place — R-8 (converted at spec.md:731); the "whichever ships first" wording is stale | 2026-09-17 |
| CL-41 | APW-09 | Should contribution (preparation and review follow-up) runs have their own monthly cap? (spec.md:735-736) | Billed like any Task, with no separate cap | Wave 2 · P2 | owner | open | — |
| CL-42 | APW-10 | Where does the tier run? (README §8 question 1) (APW-10-apps-hosting-tier/spec.md:626-627) | Rented dedicated capacity for the untrusted tier; the decision and its trade-offs are in the private operations plan | Wave 2 · P1–P2 | owner | open | — |
| CL-43 | APW-10 | Credit prices per hosting unit, and what Starter and Standard cost (spec.md:635) | Not stated | Wave 2 · P2 | owner | open | — |
| CL-44 | APW-10 | Do sandbox-incompatible App Blueprints stay Your cluster only, or does a stronger-isolation virtual-machine runtime get added? (spec.md:636-638) | They stay Your cluster only | Wave 2 · P2 → Wave 3 | owner + security | open — R-24 fixes only the timing of the sandboxed runtime | — |
| CL-45 | APW-10 | Who owns abuse handling — a named person or rota for the Medium queue and external reports, with a 24-hour response target? (spec.md:639-640) | A named person or rota, with a 24-hour response target | Wave 2 · P1–P2 | owner + legal | open | — |
| CL-46 | APW-10 | Retention after removal — is 30 days right? (spec.md:641-642) | 30 days, to be confirmed against the terms of service | Wave 2 · P2 | legal | open | — |
| CL-47 | APW-11 | Where does the platform catalog live? (APW-11-app-launcher/spec.md:694-697) | A public ever-works/platforms repository read by Ever Works, relocatable by configuration; revisit when P2 ships | Wave 1 · P1 | owner | decided in place — owner decision 2026-09-17, converted at spec.md:698; R-29 names the repository | 2026-09-17 |
| CL-48 | APW-11 | Where is the launcher web component published? (README §8 question 7) (spec.md:708-714) | Developed in the Ever Works monorepo during P1; extracted with history to a public ever-co repository and published under @ever-co at P2 | Wave 1 → Wave 3 · P2 | owner | open — README §8 question 7 :478 already points here as "CL-xx" and wants the concrete id | — |
| CL-49 | APW-11 | Which platforms are in the first catalog? (spec.md:715-720) | Ever Works, Ever Gauzy and Ever Teams are certain; Ever Rec and others need a named owner per entry | Wave 1 · P1 | owner | open | — |
| CL-50 | APW-11 | Should the launcher appear on public marketing sites? (spec.md:721-724) | No — dashboards only, even though P2 supports a signed-out platform list | Wave 3 · P2 | owner | open | — |
| CL-51 | APW-11 | Exposure default for non-App Works (spec.md:725-728) | Off, so the launcher stays about apps rather than every website | Wave 1 · P1 | owner | open | — |
| CL-52 | APW-11 | Should App Works on a person's own cluster count as live? (spec.md:729-733) | Yes — a succeeded production deployment plus an address; the launcher does not probe reachability | Wave 1 · P1 | owner | open — R-27 keeps every deploy shape | — |
| CL-53 | APW-12 | Does Ever ID itself offer Google and GitHub sign-in? (APW-12-ever-id/spec.md:593-595) | Yes, with linking at Ever ID also explicit | Wave 2 · P1 | owner + security | default accepted — idp-options.md §6 D4 (:186): "yes, with R7 linking" | — |
| CL-54 | APW-12 | Sign-up through Ever ID on Ever Works — should a private installation default it off? (spec.md:596-597) | On (FR-2) | Wave 2 · P1 | owner | default accepted for the registration half — idp-options.md §6 D6 (:188); the private-installation half stays open | — |
| CL-55 | APW-12 | Delegated token lifetime — Ever Works accepts up to 3,600 s; the recommendation to Ever ID is 900 s (spec.md:598-599) | 900 s recommended, and the relying parties assume it | Wave 2 · P1 | security | default accepted — idp-options.md §6.1 (:200): access token 900 s / ID token 300 s | — |
| CL-56 | APW-12 | Consent for apps:read — a consent screen at first use, or pre-approved for first-party Ever apps? (spec.md:600-601) | Pre-approved for first-party clients only, listed and revocable on the card | Wave 2 · P1 | security + owner | default accepted — idp-options.md §6 D7 (:189) | — |
| CL-57 | APW-12 | Does another product line's identity provider ever federate with Ever ID? (spec.md:602-603) | No; the Ever instance stays separate, with no nudge to connect in P1 | Wave 3 · P2–P3 | owner | default accepted — idp-options.md §6 D9 (:191); R-28 fixes the "pure addition" posture | — |
| CL-58 | APW-13 | Which Cal.diy repository does the golden-path lane link? (APW-13-golden-paths/spec.md:592-597) | A person creates one fork (or a private copy) once in the test fork organization; the lane only links it and proves the fork step on the fixture | Wave 1 · P1 | owner | open | — |
| CL-59 | APW-13 | Where do the test clusters live? (spec.md:598-603) | A dedicated test cluster hosting neither Ever Works nor any production product, claimed through the operations change process before each run | Wave 1 · P1 | owner (operations) | open | — |
| CL-60 | APW-13 | Who owns the model spend for the nightly and weekly lanes? (spec.md:604-607) | A dedicated test budget with the §4.6 caps; lanes fail rather than exceed it | Wave 1 · P1 | owner | open | — |
| CL-61 | APW-13 | Pass-streak lengths (spec.md:608-610) | 5 nightly or 3 weekly consecutive passes; 2 consecutive failures to unverify | Wave 1 · P1 | owner + QA | open | — |
| CL-62 | APW-13 | Signup on Cal.diy App Works — overlay Dockerfile or runtime check? (spec.md:611-618) | Leave signup as upstream ships it, state it on the create form, and decide after the first verification run | Wave 1 · P1 | engineering + owner | open | — |
| CL-63 | APW-13 | Request bodies in smoke tests (Umami's "default password refused" check) (spec.md:619-623) | The verification lane asserts it until APW-06 decides whether smoke calls take bodies | Wave 1 · P1 | engineering (APW-06) | open | — |
| CL-64 | APW-13 | The injection fixture's visibility (spec.md:624-628) | Public within the test organization, with a banner stating it is a hostile test fixture; never referenced from product documentation | Wave 1 · P1 | security + owner | open | — |
65 rows: 52 open, 8 default accepted, 5 decided in place (four by a Resolution — R-4, R-8, R-9,
R-21 — and one by owner decision, CL-47).
2. Rows that are decided, and marker text that is stale
Every conversion here is a rewrite of the marker in place: the marker keeps its text and gains the answer, which is the form the epics already use. Nothing is deleted.
2.1 Already converted in the tree (verified 2026-09-17)
| Row | spec.md:line | Converted line | What it now says |
|---|---|---|---|
| CL-35 | APW-08-evolve-loop/spec.md:781 | :784 — _Register CL-08-3 — status: default accepted for P1._ **Resolved (R-9, CONTRACTS §0)** | R-9 puts the checks in the build workflow, so the question is answered for P1. |
| CL-36 | APW-08-evolve-loop/spec.md:789 | :792 — _Register CL-08-4 — status: resolved._ **Resolved (R-21, CONTRACTS §0)** | The bootstrapping half is settled by R-21; an explicit per-App-Work setting stays optional. |
| CL-40 | APW-09-upstream-pull-requests/spec.md:729 | :731 — _Register CL-40 — status: **resolved-by R-8** (2026-09-17)._ **Resolved (R-8, CONTRACTS §0)** | APW-02 creates the tab; APW-09 adds its section. |
| CL-47 | APW-11-app-launcher/spec.md:694 | :698 — **Resolved (owner, 2026-09-17):** the repository is ever-works/platforms … | The repository exists and is what EVER_WORKS_PLATFORM_CATALOG_REPO defaults to; R-29 makes that binding. |
Two id schemes are now live, and this is the one divergence to settle. APW-09 :731 cites CL-40 —
this register's flat id — while APW-08 :784,792 cite CL-08-3 and CL-08-4, a per-epic
CL-<epic>-<n> scheme this register does not use. Both refer to rows in §1. They cannot both be the convention:
a per-epic scheme is unambiguous only while the epic's own numbering is known, and the flat ids are the ones
README §8 :475,478 and TRACKER already point at. Recommendation: keep the
flat CL-nn ids and add the per-epic alias as an annotation — CL-35 (CL-08-3), CL-36 (CL-08-4) — so both
citations keep resolving and neither is deleted. The lead owns that edit.
2.2 Not yet converted, but narrowed or settled by a binding artifact
| Row | spec.md:line | What is stale or already answered | The binding artifact |
|---|---|---|---|
| CL-19 | APW-05-builds/spec.md:706-707 | The marker asks whether to propose the workflow as a pull request. | R-4: a repository the App Work created → one direct commit; Link → always a pull request. The residual ask (a per-App-Work switch) stays optional. |
| CL-16 | APW-05-builds/spec.md:694-696 | The marker asks which builder implements auto. | R-13: auto = the build plugin detects the language/framework; which builder implements it is a plugin choice, never named in the App spec. The Wave 1 refusal stays open. |
| CL-10 | APW-03-app-spec-and-catalog/spec.md:760-766 | The marker re-asks whether an agreement must be recorded at all. | R-3: an amber app runs on Ever Works Apps only with a recorded upstream agreement. The scope question stays open. |
| CL-24 | APW-06-app-runtime/spec.md:811-813 | The marker re-opens what deletion does with stored data. | R-15: keeps volumes and App dependencies unless the owner ticks "Also delete stored data" and types the slug; the namespace default-deny policy stays; kept in-cluster dependency workloads are stopped while the data remains. |
| CL-29 | APW-07-app-env-and-dependencies/spec.md:653-655 | The same question, from the dependency side. | R-15, as above. |
| CL-23 | APW-06-app-runtime/spec.md:807-808 | The marker reads as if the address shapes were still in play. | R-16 and README §2 D10 settle the shapes (all three supported; EVER_WORKS_APPS_DOMAIN defaults to EVER_WORKS_DOMAIN). The managed-tier timing stays open. |
| CL-25 | APW-06-app-runtime/spec.md:814-815 | The marker asks whether managed auto-deploy is on by default. | Not settled — but R-30 requires the switch EVER_WORKS_APP_AUTO_DEPLOY_ENABLED either way, so it is a default choice, not a design question. |
| CL-21 | APW-05-builds/spec.md:710-711 | The marker asks whether ordinary pushes get a build-minute cap. | Not settled — but R-31 requires every unbounded action to have a documented cap with an environment override, so the answer has a mandated shape. |
| CL-39 | APW-09-upstream-pull-requests/spec.md:723-724 | The marker asks for daily limit numbers. | Not settled — R-31 supplies the mechanism (per member and per organization, with a refusal code). |
| CL-53…CL-57 | APW-12-ever-id/spec.md:593,596,598,600,602 | The five open APW-12 markers each have a recommended default in the epic's own decision record. | idp-options.md §6 D4 :186, D6 :188, D7 :189, D9 :191, and §6.1 :200; R-28 fixes the provider, the domain and the "pure addition" posture. idp-options.md:215 records that D2–D9 remain open recommendations, so these are default accepted, not owner decisions. |
2.3 Three facts in the audit's own artifacts that are now stale
- "Only APW-06 marks settled questions as 'Resolved (CONTRACTS C2)'." Eight epics now do it, in four house
forms:
APW-02:627,APW-03:739-752,APW-06:805,809,APW-07:642,644,APW-08:784,792,APW-09:731,APW-10:614-628,APW-11:698,APW-12:588. The conversions below have precedent to copy rather than a convention to invent. - The marker count. Both the audit rows and
_build-artifacts/open-decisions/decision-sheet.md:25quote 66; the tree has 66 occurrences of the literal string but 65 open markers, becauseAPW-12-ever-id/spec.md:588is a struck-through, answered marker that still contains the string. The audit's per-epic breakdown is also wrong in two places and right only by accident in the total — §5 has the recount. - The resolution range. The audit says
R-1…R-25; the tree now runs toR-1…R-39(rows were added by other workstreams after the audit —R-28Ever ID provider,R-29catalog repositories,R-30operator kill switches,R-31quotas and caps, and others). This register proposes no new id: where a marker looks like it wants a resolution, it cites the existingR-nthat narrows it and staysopenfor the residual question.
3. Programme-level open questions, and which of them have a marker
README §8 holds ten owner questions (:447-491). Some are
restated as an epic §9 marker and are therefore rows above; some are answered; four have no marker anywhere,
which means they gate no epic's approval and can be lost between documents. They are recorded here so the
register is a complete view, and they are not given CL-nn rows — a row should correspond to a marker a
lead can convert in place.
| README §8 | Line | Question | Restated as | State |
|---|---|---|---|---|
| Q1 | :451 | Managed hosting location for Wave 2 | CL-42 (APW-10:626) | open — still the owner's call |
| Q2 | :455 | User-apps apex domain | answered 2026-09-17 | answered — EVER_WORKS_APPS_DOMAIN defaults to EVER_WORKS_DOMAIN; README §2 D10, R-16, and APW-10:628 |
| Q3 | :461 | Free tier — may unverified/free users run code on the managed tier? | no marker | open at programme level; default recorded (no — Wave 2 requires a verified, paying account) |
| Q4 | :463 | Blueprint repository naming (<app>-template collides with Website Templates) | no marker | open at programme level; default recorded (keep <app>-template + the ever-works-app-blueprint topic + a valid App spec) — R-29 and CONTRACTS §8 :523-524 carry the detail |
| Q5 | :466 | Default fork visibility / how prominently Private copy is offered | no marker | open at programme level; default recorded (Fork is default; Private copy one click, with the upstream-PR trade-off shown) |
| Q6 | :468 | Ever ID identity provider and domain | answered — and §9 already points here | answered (ZITADEL, self-hosted as-is, auth.ever.co) — R-28, APW-12:588-592, idp-options.md §6 D1 :183. CL-53…CL-57 carry the residual D4–D9 questions |
| Q7 | :476 | Where the App Launcher web component is published | CL-48 (APW-11:708) | open — and §8 :478 already points at this register as "CL-xx", so it wants the concrete id CL-48 |
| Q8 | :480 | First golden path (fixture app and Umami before Cal.diy) | no marker | open at programme level; default recorded (fixture app + Umami first, Cal.diy as the flagship) — APW-13's whole epic is built on it |
| Q9 | :482 | Single sign-on into a user's own App Works, and in which wave | no marker | open at programme level; default recorded (not in Waves 1–2, D14) — this is the question behind G-09's copy ban |
| Q10 | :486 | Does the managed-tier Cal.diy run belong to Wave 2's exit criteria? | CL-08 (APW-03:754) — same subject | open; default recorded (keep it out of Wave 2's exit criteria and say so in ACCEPTANCE §4) |
4. Wave impact
Each row is counted once, in the earliest wave it appears in. Three rows recur later: CL-48 (the launcher web
component) publishes in Wave 1 and is extracted to ever-co at P2; CL-23 (custom domains on Ever Works Apps)
and CL-44 (a stronger-isolation runtime) start in Wave 2 and their own marker text defers the decision to
Wave 3.
| Wave / phase | Markers | Count |
|---|---|---|
| Wave 0 · P0 (APW-08 P0, APW-02 P0) | none — no §9 marker sits in a P0 phase | 0 |
| Wave 1 · P1 (and rows that start there) | CL-01…CL-07, CL-09, CL-11…CL-19, CL-21, CL-24, CL-26…CL-29, CL-31, CL-33…CL-37, CL-40, CL-47, CL-48 (→ Wave 3), CL-49, CL-51, CL-52, CL-58…CL-64, CL-65 | 43 |
| Wave 2 · P1–P2 (and rows that start there) | CL-08, CL-10, CL-22, CL-23 (→ Wave 3), CL-25, CL-30, CL-32, CL-38, CL-39, CL-41, CL-42, CL-43, CL-44 (→ Wave 3), CL-45, CL-46, CL-53, CL-54, CL-55, CL-56 | 19 |
| Wave 3 · P2–P3 | CL-20, CL-50, CL-57 | 3 |
| Not wave-bound (a policy or documentation call) | none | 0 |
| Total | 65 |
The 43 Wave 1 rows are not 43 blockers in the ordinary sense: every one of them has a stated default the
epics already build against, which is why Wave 0 is unaffected and Wave 1 can start. Eight of them need only
to be written down — the four decided in place with a marker inside Wave 1 (CL-35, CL-36, CL-40, CL-47) plus
the four Wave 1 rows that are settled and not yet converted (CL-19 by R-4, and CL-24, CL-29, CL-33 as
default accepted). The remaining 35 are owner, legal, security or engineering calls whose default is safe
to ship behind, which is the same conclusion BUILD-READINESS.md reaches from the other
direction.
Across all waves: 13 rows are already decided (8 default accepted + 5 decided in place) and 52 stay
open for a person.
5. Recount — 66 literal occurrences, 65 open markers
Method, run from the worktree root — re-runnable at any time, and the one to use if the tree has moved:
grep -rc "NEEDS CLARIFICATION" docs/specs/features/app-works/APW-*/spec.md
| Epic | Literal occurrences | Open markers | Notes |
|---|---|---|---|
| APW-01 | 4 | 4 | spec.md:759,761,763,765 |
| APW-02 | 4 | 4 | spec.md:630,632,634,635. The audit counted 3; the 2026-09-17 audit added a fourth (:635, registered here as CL-65). :625,627 are the §9 heading and a Resolved (Resolution R-21) line, which do not carry the string |
| APW-03 | 3 | 3 | spec.md:754,757,760; :739-752 is the resolved block |
| APW-04 | 5 | 5 | spec.md:663,666,668,670,672 |
| APW-05 | 6 | 6 | spec.md:694,697,704,706,708,710 |
| APW-06 | 5 | 5 | spec.md:801,807,811,814,816; :805,809 are Resolved (CONTRACTS C2) |
| APW-07 | 6 | 6 | spec.md:647,650,653,656,659,662; :642,644 are Resolved (…) |
| APW-08 | 5 | 5 | spec.md:774,777,781,789,796; :784,792 are the inline Resolved (R-9) / Resolved (R-21) conversions |
| APW-09 | 4 | 4 | spec.md:716,723,729,735; :731 is the inline Resolved (R-8) conversion |
| APW-10 | 5 | 5 | spec.md:626,635,636,639,641. The audit says 6. :614 is ## 9. Open questions, :616-622 is the resolved block, and :628 was answered on 2026-09-17 — it now reads [ANSWERED 2026-09-17 — which apex domain?] and no longer carries the string |
| APW-11 | 6 | 6 | spec.md:694,708,715,721,725,729; :698 is the inline owner conversion for CL-47 |
| APW-12 | 6 | 5 | spec.md:593,596,598,600,602 are open; :588 is a struck-through, ANSWERED marker and still contains the string, which is why the two columns differ |
| APW-13 | 7 | 7 | spec.md:592,598,604,608,611,619,624 |
| Total | 66 | 65 | Per-epic breakdown: APW-01 4 · 02 4 · 03 3 · 04 5 · 05 6 · 06 5 · 07 6 · 08 5 · 09 4 · 10 5 · 11 6 · 12 6 · 13 7 |
Where the other numbers come from, and why they differ:
- The audit's
66is right for the wrong per-epic reasons: it counted APW-02 3 and APW-10 6, which cancelled a marker APW-10 had already lost (answered 2026-09-17) against one APW-02 had gained (added by the same audit). Anyone reading only the total would conclude nothing had changed. - The audit's
12: 6counts the struck-through, answered marker atAPW-12:588; the open count for APW-12 is 5. - BUILD-READINESS.md
:154records 65 remaining, which matches today's open count by coincidence rather than by the same arithmetic. _build-artifacts/open-decisions/decision-sheet.md:25records 66 unresolved, which is the literal count rather than the open count..specify/templates/spec-template.md:86-91and every epic's §9 use the marker form, so this recount is reproducible with onegrep; nothing here depends on reading a summary.
Nothing in plan.md or tasks.md. The string appears in no epic's plan.md or tasks.md. Outside the
epics it appears only in the audit artifacts (BUILD-READINESS.md:154,
_build-artifacts/open-decisions/decision-sheet.md, contradictions.md, build-readiness.md), which quote
the count rather than define a marker.
6. What this register does not do
- It does not edit any epic's §9. Converting a marker in place is a change inside an
APW-xx-*folder, which the program lead owns; the exact proposed replacement text for each row is listed in the shared-file requests delivered with this document. - It does not invent a Resolution id. Rows that look like they want one (
CL-10,CL-16,CL-21,CL-23,CL-25,CL-39,CL-44,CL-52) cite the existingR-nthat already narrows them and stayopenfor the residual question. Rows the owner later decides become decisions in README §2 or new resolutions in CONTRACTS §0 — both of which this register then cites. No id above the current last resolution is proposed here; idsR-28…R-39already exist and were added by other workstreams. - It does not mark anything "not applicable" or "obsolete". A row whose question has been overtaken keeps its id and its question, and gains a status.
- It does not change TRACKER.md's
Reviewed/Approvedladder; that criterion now lives in TRACKER:65-79, andchecklists/requirements.mdis the checklist it names. - It does not renumber. CL-65 was appended when the 2026-09-17 audit added APW-02's fourth marker, rather
than renumbering CL-08…CL-64, because APW-09
:731and README §8:475,478already cite ids from this register.