create-githolon 0.16.3 → 0.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-githolon",
-  "version": "0.16.3",
+  "version": "0.18.0",
   "type": "module",
   "description": "Scaffold a Nomos domain package: the starter domain + compile config + live e2e. `npm create githolon my-app`.",
   "license": "SEE LICENSE IN LICENSE.md",

package/template/docs/04-cloud.md

@@ -22,8 +22,8 @@ the principal births will ride; sessions auto-refresh from
 **Path A — deploy your law** (the cloud births the workspace):
 
 ```bash
-npx githolon ws create <ws>   # birth; the ONE-TIME workspaceSecret is saved to ~/.holon
-npx githolon deploy <ws>      # POST build/<pkg>.deploy.json with the stored secret
+npx githolon ws create <ws>   # birth; NO secret is minted — ownership is a law fact in the chain
+npx githolon deploy <ws>      # POST build/<pkg>.deploy.json, authenticated as your principal
 ```
 
 **Path B — the upload birth** (you birth it, the cloud verifies):
@@ -38,18 +38,23 @@ proves itself either way ([05-superpowers.md](./05-superpowers.md) walks B).
 
 ## Ownership
 
-The workspace secret gates LAW (deploys, retirement, secret rotation). End-user
-apps carry NO secret: reads and session pushes are open, judged by edge
-admission; the session lane structurally refuses control-plane intents. So law
-only ever enters through the secret-gated deploy. Lose the secret? It was
-shown once — `githolon secret rotate` with the current one, or ask the
-operator. Never embed it in an app.
+There is no host secret. Ownership is a LAW FACT bound IN THE CHAIN —
+`sha256(the push password)` written onto the law record at the upload birth (push
+with no password ⇒ born OPEN). Born-ness derives from custody (the ledger has a
+`main`); `/boot` returns no secret. DEPLOY write-authority is judged by the
+KERNEL at the offer gate — you authenticate as a principal the law grants deploy
+authority (`x-nomos-auth`, or transitionally `x-nomos-principal`), not a Bearer
+secret. End-user apps carry no credential: reads and session pushes are open,
+judged by edge admission; the session lane structurally refuses control-plane
+intents. So law only ever enters through a deploy the kernel authorizes. There is
+nothing host-side to rotate (`/rotate-secret` is retired, 410); to re-own, re-birth
+via the upload lane with a new push password — or ask the operator.
 
 ## Dead-letter retry — the operator's unjam
 
 Domain-rejected intents land in the workspace DLQ with full provenance
-(`GET /v1/workspaces/<ws>/dead-letters`, owner-keyed). Ship the law fix via
-the deploy lane, then `POST /v1/workspaces/<ws>/dead-letters/retry?id=` (or
+(`GET /v2/workspaces/<ws>/dead-letters`, owner-keyed). Ship the law fix via
+the deploy lane, then `POST /v2/workspaces/<ws>/dead-letters/retry?id=` (or
 client-side `retryDeadLetter(id)`). The refused work — somebody's actual
 writes — lands on main. DELETE discards, explicitly.
 

package/template/docs/07-security.md

@@ -31,8 +31,9 @@ export const Note = aggregate("Note",
 // (the bindings the read gate reads). Forgetting this is the #1 mistake.
 export const UserPermission = userPermissionAggregate;
 
-// The owner bestows the cap on a reader. Authored through the secret-gated
-// `/author` lane (or `githolon author`) — only the owner can grant.
+// The owner bestows the cap on a reader. Authored through the gateway offer lane
+// (`POST /v2/workspaces/<ws>/grantReader`, authenticated as the owning principal) —
+// write-authority is kernel-judged at the offer gate; there is no host secret.
 export const grantReader = directive("grantReader").ensures(UserPermission)
   .payload(z.object({ principal: z.string(), grantedBy: z.string(), grantedAt: z.string() }))
   .plan((p) => grant({
@@ -71,9 +72,11 @@ How it behaves:
   the maintained projection — cost scales with the number of *identities*, not
   your data volume (revoking one reader over 10k private records stays fast).
 
-The owner grants through the secret-gated lane; your end-user app carries **no
-secret** — its writes are judged by edge admission, and it simply can't author a
-grant. Authority enters only through the owner.
+The owner grants through the gateway offer lane, authenticated as the owning
+principal (write-authority is kernel-judged at the offer gate — no host secret);
+your end-user app carries **no** credential — its writes are judged by edge
+admission, and it simply can't author a grant. Authority enters only through a
+principal the law authorizes.
 
 ## Layer 2 — encrypted fields: operator-blind, end-to-end