docs(plan): correct the SPEC-010 gate note (all packages, not a package count)
This commit is contained in:
parent
3a258aeb55
commit
61b723736e
1 changed files with 1 additions and 1 deletions
|
|
@ -661,4 +661,4 @@ shell/layout lives in `core/web`; a module's views live with the module.
|
|||
| 2026-10-15 | **D-044 ✅ IMPLEMENTED — the setup code + the first-run boilerplate (D-025 re-revised).** The real topology is **LXC (11020) behind Proxmox + Zoraxy**, so the SSH tunnel is impractical (it lands on the container *gateway*, not loopback). `core/setup` gains a **`Gate`** — a **128-bit setup code** (generated at first run, printed in an unmistakable **startup banner**; `setup_code` overrides it) plus a **signed unlock cookie** (`myday_setup`, carrying a keyed one-way **fingerprint**, never the code). The door (`Deps.SetupGate`) now serves the **wizard** to **either** the tunnel **(a)** or an **unlocked** request **(b)**; `GET /` and an un-unlocked `GET /setup` render a friendly **first-run page** with the code form — **never a bare 404**, so the domain stops looking "down" — and every other route stays 404. The unlock is **single-use**, **rate-limited** (the `/setup` A3 class), **CSRF-protected (A15)** and **redacted** (A8); a wrong/absent code gets a **generic 403**. New: `httpx.Signer.Fingerprint` · `config.setup_code` · `setup.Gate` (`gate.go`) · the `unlock` action · `server.SetupGate`/`serveBoilerplate`. Docs: `deploy-zoraxy.md` §5 rewritten for the LXC/Proxmox + code flow (tunnel kept as gate a), README first-run/deploy sections, SPEC-003 §7/§9 (AC-7 · AC-10 · AC-14) and SPEC-005 §3/§4/§6/§9. Gate green (`build` · `vet` · `test -race`) · **static CGO-free** binary · `routing` purity intact. **Live smoke** (real binary, proxy-style `X-Forwarded-For`): the banner prints the code · `/` and `/setup` → **200 boilerplate** · `/home` → **404** · the tunnel → the wizard · wrong code → **403 generic** · correct code → **303** + unlock cookie → the wizard · a spent code → **403** · the code absent from the access log and redacted when hand-typed into the query. |
|
||||
| 2026-10-15 | **Setup gate simplified to the config toggle (D-045).** `setup: true` enables `/setup` at the **public domain**; **completion writes `setup: false`**; `setup: false` + no admin → a **locked boilerplate** (not claimable); the **setup code becomes OPTIONAL**; the **peer/tunnel gate is retired** (D-025 superseded). **Residual:** while `setup: true`, whoever reaches `/setup` first can claim the admin — set `setup_code` or finish immediately. SPEC-005 §3/§4 revised. |
|
||||
| 2026-10-15 | **D-045 ✅ IMPLEMENTED — the toggle gate, the optional code, the retired tunnel.** The gate is `config.setup`: **`setup: true`** → `/setup` serves the **wizard** (or the **code form** first when `setup_code` is set, D-044); **`setup: false` + no admin** → the **LOCKED** state (`/` and `/setup` show an "enable setup" boilerplate, every other route 404, **not claimable**); **completion** writes **`setup: false`**. `setup.New` **no longer generates a code** — blank ⇒ `Gate.Required()` false ⇒ the toggle alone admits. **Retired:** `httpx.SetupRequestAllowed` + `httpx.IsLoopbackIP` (deleted) and the `!bootstrapped()` fail-safe (now the locked predicate, latched at startup). **Kept:** the XFF/XFP handling for the **client IP** and the `Secure`/`__Host-` cookies + HSTS (A6/A11/D-043). New door seams: `Deps.LockedMode`, `SetupGate.{Required,CodeForm,Landing,Locked}`; `Gate` renders three first-run pages. The **startup banner** states the mode and prints the code **only when required**; the locked state prints *"set `setup: true` and restart"*. Docs: SPEC-003 §7/§9 (AC-7 · AC-10 · AC-14), SPEC-005 §1/§3/§5/§6/§9/§10, `deploy-zoraxy.md` §1/§2/§3/§5/§7, README first-run/deploy, `config.example.yaml`, A13 · O-8 · §5.1 · D-025 superseded. Gate green (`go build` · `go vet` · `go test -race` — 18 pkgs) · **static CGO-free** binary · `routing` purity intact. **Live smoke** (real binary, all three states): locked → `/`·`/setup` **200 boilerplate**, `/home` **404**, unlock **404**; `setup: true` no code → `/setup` **wizard**, `/` **landing**, `/home` **404**; `setup: true` + code → **code form** → wrong code **403** → correct code **303** + unlock cookie → **wizard**; full bootstrap (`domain.save`→`admin.create`→`admin.totp.begin/verify`→`finish`) → `config.yaml` **`setup: false`** → `/setup` **404**, `/` **302**. |
|
||||
| 2026-10-15 | **SPEC-010 ✅ IMPLEMENTED → M0.2 (the admin & account UI).** The live instance had **no nav, no way to add a user and no way to add a passkey** — the services existed, the UI did not. New **`internal/core/account`**: the **account page** (`GET /{GUID}/account` — passkey count · TOTP enrolled · an **Add a passkey** button that **LINKS** to the existing D-041 screen, so the WebAuthn ceremony is never duplicated · **Don't ask again** writing `users.passkey_opt_out`) and the **admin Users page** (`GET /{GUID}/users` — list name·email·role·manager·identity status; **create** with only roles **below** the creator (D-019) and the manager defaulting to the creator → `users.Create` + `identities.Mint` + **email the `/{GUID}` invite** (the mailer) and **show the link** for copy/paste). The **shell** now renders the **role-gated core nav** (Home · Account for everyone; **Users · Modules for an admin** — the registry entries ride alongside, the discovered `home` collapsed onto the core Home) and, while the signed-in user has **no passkey, has not opted out and the origin is not loopback**, a prominent **Add-a-passkey banner** — closing the D-041 gap where the wizard's **direct session mint bypasses the TOTP-login nudge** and the admin was never prompted. The door computes `(admin, banner)` in `serveGUID` (it already holds the session/identity/user) and attaches it to the request context; `web.PageFor` copies it onto every authenticated page (`RequestContext` untouched). Role gate: `/users` + `users.create` require **admin** (`server.Tiers`). Additive: `auth.Identities.TOTPEnrolled` · `users.Users.List` · `module.CoreDispatchNames` += `account·users` · `server.Deps.Credentials`. AC-1…AC-7 green (`build` · `vet` · `test -race` — 20 pkgs) · **static CGO-free** binary · `routing` purity intact · **no inline scripts**. Deviations D-1…D-5 in SPEC-010 §9. |
|
||||
| 2026-10-15 | **SPEC-010 ✅ IMPLEMENTED → M0.2 (the admin & account UI).** The live instance had **no nav, no way to add a user and no way to add a passkey** — the services existed, the UI did not. New **`internal/core/account`**: the **account page** (`GET /{GUID}/account` — passkey count · TOTP enrolled · an **Add a passkey** button that **LINKS** to the existing D-041 screen, so the WebAuthn ceremony is never duplicated · **Don't ask again** writing `users.passkey_opt_out`) and the **admin Users page** (`GET /{GUID}/users` — list name·email·role·manager·identity status; **create** with only roles **below** the creator (D-019) and the manager defaulting to the creator → `users.Create` + `identities.Mint` + **email the `/{GUID}` invite** (the mailer) and **show the link** for copy/paste). The **shell** now renders the **role-gated core nav** (Home · Account for everyone; **Users · Modules for an admin** — the registry entries ride alongside, the discovered `home` collapsed onto the core Home) and, while the signed-in user has **no passkey, has not opted out and the origin is not loopback**, a prominent **Add-a-passkey banner** — closing the D-041 gap where the wizard's **direct session mint bypasses the TOTP-login nudge** and the admin was never prompted. The door computes `(admin, banner)` in `serveGUID` (it already holds the session/identity/user) and attaches it to the request context; `web.PageFor` copies it onto every authenticated page (`RequestContext` untouched). Role gate: `/users` + `users.create` require **admin** (`server.Tiers`). Additive: `auth.Identities.TOTPEnrolled` · `users.Users.List` · `module.CoreDispatchNames` += `account·users` · `server.Deps.Credentials`. AC-1…AC-7 green (`build` · `vet` · `test -race` — all packages) · **static CGO-free** binary · `routing` purity intact · **no inline scripts**. Deviations D-1…D-5 in SPEC-010 §9. |
|
||||
|
|
|
|||
Loading…
Reference in a new issue