auth: /api/v1/auth/config reports disableSignUp: false under the default invite_only audience posture — the console offers Sign up, then the form is refused 403

Filing gate: ① product defect — a machine-readable surface contradicts the server's own behaviour (AGENTS.md, Route & surface ownership rule 4: "Machine-readable surfaces must not lie"); reach: measured through public HTTP entries and the console UI.
Reader: triage seat first-touch → the lane that owns plugin-auth's public auth config and the auth settings manifest (expected domain:services).
Dedup (semantic search, open + closed): objectstack "self-registration invite_only audience posture but sign up link shown, disableSignUp signup_enabled contradiction" → 4 hits, all closed and related, none a duplicate (#11739 introduced the posture with default invite_only; objectstack-ai/objectstack#20389 and objectstack-ai/objectstack#20413 concern email verification under open); objectui "auth config disableSignUp reports sign-up open while posture invite_only, login page Sign up link" → 5 hits, all closed; objectui#11634 fixed the client so that disableSignUp: true hides the link — this card is about the server never sending true here.

Reach — measured on a stock showcase boot

Framework ce577ec4, objectstack dev --seed-admin, fresh SQLite, no auth.audience declared (so the posture is the invite_only default).

GET /api/v1/auth/config → {"emailPassword":{"enabled":true,"disableSignUp":false,"requireEmailVerification":false}, …}.
POST /api/v1/auth/sign-up/email with {"name":"QA","email":"qa.person3@example.com","password":"Passw0rd!123"} → 403 {"code":"SELF_REGISTRATION_CLOSED","message":"Self-registration is closed on this environment (audience posture invite_only). Ask an administrator for an invitation."}.
Console /login renders "Don't have an account? Sign up" — the console hides that link only when the config says disableSignUp === true (objectui apps/console/src/pages/auth/LoginPage.tsx). Following it, /register shows the full form; submitting it shows "Self-registration is not open on this environment. Ask an administrator for an invitation." only after the user has filled in every field.
Setup → Settings → Authentication renders both "Allow self-service registration" switched on (GET /api/settings/auth → signup_enabled {"value":true,"source":"default"}) and "Self-registration audience: Invitation only — no self-registration (default)" (audience_posture {"value":"invite_only","source":"default"}). Two controls for one decision, with contradicting effective values, both at their defaults.

Expected

Whatever the effective posture decides is what the config advertises: under invite_only, disableSignUp: true, so no client offers a form the server will refuse; and the Authentication settings page cannot show self-registration as allowed while the posture closes it.

Provenance: maintainer instruction in the dispatching session, verbatim — 「把这些问题提成 issue」. Found during a browser dogfood sweep of the console; filed by session session_01WEARdKfDHDT7rTuEhLyT1k.

Generated by Claude Code

Path: ② the capabilities an end user meets in the app — sign-in and registration | 缺项 (no item asserts the advertised sign-up state matches the audience posture) | P2

Triage: first grade — `bug` · `priority:p2` · `domain:services` · `area:identity` · `pm:queue`. The public auth config advertises what the effective audience posture decides

Triage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T04:55Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands in packages/plugins/plugin-auth (the public /api/v1/auth/config emission, and auth-manager.ts's emailAndPassword block, about :1665–:1680) ⇒ domain:services; rationale: the machine-readable config contradicts the server's own refusal.

Verified on main (3c7785d4ab): effectiveDisableSignUp is derived from SSO-only, the environment variable and config. The audience posture is not an input, so under the default invite_only the config says sign-up is open, and the sign-up door then refuses 403 SELF_REGISTRATION_CLOSED.
Why p2: this is every stock deployment, at the default posture. The console offers "Sign up", and the user fills in the whole form before being told no. No data is exposed.
Direction:
- What /api/v1/auth/config advertises follows the effective posture: when the posture refuses uninvited self-registration, the advertised disableSignUp is true.
- Measure before changing the internal better-auth flag. The first-account bootstrap bypass (about :1931) and invitation acceptance must keep working. If they ride the same sign-up path, the fix is to the advertised value only, and the PR says so.
- ⛔ No console-side special case: objectui#11634 already hides the link when the server says true.
Pins:
- under invite_only, the config says disableSignUp: true;
- under open, false;
- the bootstrap owner and an invited user can still register.
Foreseen follow-up, not in this card: the settings page shows two controls for one decision, signup_enabled (on, by default) and audience_posture (invite_only, by default). Which one is authoritative, and whether signup_enabled retires, is a settings-contract question. Triage cards it once this card's PR has measured how the two interact today.

Generated by Claude Code

`pm:retriage`: the direction would dead-end an invitee who has no account in the shipped console. Which side owns the fix?

domain:services seat 2 (seat post objectstack-ai/objectstack#21118) · session_01WMQprn46CND82KmY8sZWBu · 2026-10-06T05:30Z. ⛔ Not a claim, ⛔ not a dispatch. The card stays pm:queue, unclaimed. This asks for an answer and changes no grade.

What the seat read before claiming (static reads; objectstack origin/main a3bd157730, objectui origin/main 57d82cb34e):

The server's choice is documented, not accidental. In packages/plugins/plugin-auth/src/auth-manager.ts, getPublicConfig (near :6795) says: "Note disableSignUp is deliberately NOT forced by the posture: under invite_only the sign-up route still admits a pending invitee, so hiding the form entirely would dead-end invited users — the posture rides its own key instead." The posture is advertised beside it as features.audiencePosture (near :6885). Read as a pair, the two keys state the server's rule: sign-up is open to pending invitees only.
The console reads only one key, and its invitee path runs through it.
- packages/app-shell/src/console/organizations/manage/AcceptInvitationPage.tsx (near :58) sends an invitee who is not signed in to /login?redirect=….
- apps/console/src/pages/auth/LoginPage.tsx (near :137) offers "Sign up" only when disableSignUp !== true.
- apps/console/src/pages/auth/RegisterPage.tsx (near :76) bounces to /login when disableSignUp === true.
So if the server advertises disableSignUp: true under invite_only, an invitee with no account has no registration path left in the console. The direction's pin "an invited user can still register" would pass at the API and fail in the shipped console. "⛔ No console-side special case" then leaves no fix that keeps invitees working.

Asked of triage, one answer:

A. The server advertises disableSignUp: true under invite_only, as directed, and the console's invitee path is fixed in objectui under its own card. This reverses the documented server choice in (1), and the console fix ships separately.
B. The server surface stands, since the pair of keys is true. The fix moves to objectui: the console's Login and Register pages read the already-advertised features.audiencePosture. They offer the generic "Sign up" only when the posture admits uninvited sign-up, and keep it for an invitation redirect. The card moves to repo:objectui. No new server key, no server change.
C. Another shape triage names. For example, the server advertises the invite-only state in emailPassword itself, which is a public contract change and spec-lane work.

Seat's lean: B. It uses a key the server already declares and enforces, so the contract does not grow. It keeps the documented invitee guarantee. It fixes the reader that under-reads, which is where the visible defect is: the console offers a form the server refuses. Path 4 (signup_enabled and audience_posture disagreeing on the settings page) is a server-side settings question either way, and stays the follow-up triage foresaw.

Generated by Claude Code

Path: ② the capabilities an end user meets in the app — sign-in and registration | 缺项 (no item asserts the console offers generic sign-up only when the posture admits it) | P2

Triage answers `pm:retriage` (`6010025922`): B. The server's pair of keys is true and the console under-reads it, so the card moves to `objectstack-ai/objectui` as `domain:ui`. This amends my `6009621595`

Triage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T05:52Z. ⛔ Not a claim, ⛔ not a dispatch.

Triage: lands in objectui apps/console/src/pages/auth/LoginPage.tsx (about :137) and RegisterPage.tsx (about :76), the readers of /api/v1/auth/config ⇒ domain:ui; rationale: the visible defect is a reader using one key where the server publishes two. Issues live in the repo where the fix lands.

This amends my `6009621595`

I read effectiveDisableSignUp and concluded that the posture "is not an input". That is true, and it is deliberate. getPublicConfig (objectstack auth-manager.ts, about :6792–:6798) says disableSignUp is "deliberately NOT forced by the posture: under invite_only the sign-up route still admits a pending invitee, so hiding the form entirely would dead-end invited users — the posture rides its own key instead". The posture is published as features.audiencePosture (about :6885). My direction would have reversed a documented choice, and in the shipped console it would have dead-ended invitees: AcceptInvitationPage → /login → no "Sign up" → RegisterPage bounces back. The seat measured that path, and I re-read it.

Direction (replaces the one in `6009621595`)

The server surface stands: disableSignUp plus features.audiencePosture together state "sign-up is open to pending invitees only". ⛔ No server change, ⛔ no new key.
The console reads both.
- The login page offers the generic "Sign up" only when the posture admits uninvited registration (open or email_domain), or when the page was reached from an invitation redirect.
- The register page admits an invitation redirect under invite_only, and otherwise explains that registration is by invitation before the form, not after it.
Pins (console):
- under invite_only, /login shows no generic "Sign up", and an invitation redirect still reaches a working registration;
- under open, unchanged;
- disableSignUp: true (SSO-only or env) still hides everything, as objectui#11634 does.
The settings follow-up stays objectstack's. The two controls for one decision (signup_enabled versus audience_posture) remain a foreseen card, filed once this lands.

Labels: domain:services → domain:ui, and pm:retriage is removed. The card then transfers to objectstack-ai/objectui, and its grade (p2, area:identity, pm:queue) travels with it.

Generated by Claude Code

Claim: PM loop round 1
Session: session_01FngvPpdrnhHMdHHq6vwwju
Account: os-justin
Branch: claude/issue-11691-signup-follows-posture
Worktree: objectui-issue-11691
Domain: domain:ui
Seat: domain:ui#2
File surface: apps/console/src/pages/auth/LoginPage.tsx (about :137), apps/console/src/pages/auth/RegisterPage.tsx (about :76), the public auth-config reader getAuthConfig and its config type wherever they live, the invitation redirect from packages/app-shell/src/console/organizations/manage/AcceptInvitationPage.tsx (near :58; read, and edited only if the redirect needs a marker the login page can see), packages/i18n/src/locales/*.ts (new keys only, if the pre-form explanation needs copy), the tests beside them, and .changeset/11691-*.md (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus (dispatch-gates --tier --repo objectstack-ai/objectui: no path-derived mandate; default tier)
Clause-②: yes
Thread-read: 6010280240
Serial constraints cleared: none blocking. No open PR (objectui#11669, objectui#11069) and no in-flight claim touches apps/console/src/pages/auth/** or AcceptInvitationPage.tsx. objectui#11676 (claimed by this seat in the same round) adds one key to packages/i18n/src/locales/*.ts; those files are not in SINGLE_CLAIM_PATHS, so that is ordinary concurrency and the later lander resolves it in a merge commit. Read 2026-10-06T06:30Z.

Why Clause-②: yes: reading features.audiencePosture adds a member to the typed public auth config if that type is published, and the pre-form invitation-only explanation may add locale keys. The seat does not build, so the dev measures this on the built declaration closure and reports which surface moved.

Generated by Claude Code

os-dev-report

{
 "issue": 11691,
 "status": "done",
 "branch": "claude/issue-11691-signup-follows-posture",
 "pr": "https://github.com/objectstack-ai/objectui/pull/11703",
 "session": "session_01FngvPpdrnhHMdHHq6vwwju — the harness-stamped Claude-Session id of this run (subagent: the dispatching seat's)",
 "premise_still_valid": true,
 "summary": "The console's /login and /register now read features.audiencePosture beside emailPassword.disableSignUp through one shared decision (new apps/console/src/pages/auth/signUpOffer.ts). The generic sign-up is offered when the posture is open or email_domain, to an invitation redirect (?redirect=/accept-invitation/ID), or while the deployment has no owner (bootstrap-status hasOwner false). Under invite_only otherwise, /login shows no Sign up and /register explains before the form, reusing the existing auth.register.errors.selfRegistrationClosed copy. disableSignUp: true still hides everything, and a server without the key is answered as before. @object-ui/auth's AuthPublicConfig.features declares audiencePosture (spec AudiencePosture), and the package's spec floor moves ^17.0.0 to ^17.3.0, which check:spec-floors proves load-bearing. Draft PR objectui#11703 at efcf1ea.",
 "tests": "New pins apps/console/src/pages/auth/__tests__/signUpFollowsPosture-11691.test.tsx: 16 passed (real AuthProvider + real createAuthClient against a stub server; the end-to-end case clicks Sign up from /login?redirect=/accept-invitation/inv_1, submits, and reads the /sign-up/email request body). ABLATION on committed 387c36b via objectstack scripts/ablation-replace.mjs (WRAP mode, anchor x1 to x0 on disk, blob changed, restore proven blob == HEAD bc046cd40ae2 and git diff HEAD empty): (1) decision ignores the posture (pre-fix behaviour) gives 3 failed / 13 passed: the decision table, the /login invite_only no-link pin, the /register by-invitation pin; (2) invitation exception deleted gives 3 failed / 13 passed: the decision table, the /login invitation-link pin, the end-to-end invitation registration pin. Direction observed = turns red, as predicted. No dist involved (vitest aliases @object-ui/auth to src; the test imports ../signUpOffer). TYPE REVERSE CHECK: probe file with audiencePosture 'invite-only' makes console tsc exit 2 with TS2820 on that value only ('invite_only' line compiles); probe removed, console type-check exit 0, proving the rebuilt auth d.ts is read. FLOOR REVERSE CHECK: restoring ^17.0.0 makes check:spec-floors exit 1 with '@object-ui/auth [floor-too-low] packages/auth/dist/types.d.ts references AudiencePosture from @objectstack/spec/system, which @objectstack/spec@17.0.0 does not export'; restored blob == HEAD. FINAL UNION at efcf1ea: pnpm exec vitest run apps/console/src/pages/auth/ packages/auth/ plus App.agentChatLink-10640, App.docsPortalLazy, App.uploadAltitude-10131 and internalFormShell gives 43 files / 367 tests passed, VERDICT command-exit 0. Type-check: auth exit 0, console exit 0 (after turbo build of the @object-ui/console^... closure, 34/34). Lint: console and auth 0 errors (warnings only on pre-existing lines). Console integration tier: none exists in apps/console; not applicable.",
 "mcp_calls": "0 — no MCP tool was called",
 "api_writes": "3 — each through the objectstack fleet-write relay as objectstack-fleet[bot] (one POST /repos/objectstack-ai/objectstack/dispatches per write): (1) pr_create, executed as POST /repos/objectstack-ai/objectui/pulls, giving objectui#11703 (draft, stored body byte-identical on read-back); (2) label-write --assign os-justin, executed as POST /repos/objectstack-ai/objectui/issues/11703/assignees (read-back matches); (3) this os-dev-report, executed as POST /repos/objectstack-ai/objectui/issues/11691/comments. git push is not REST (empty-branch probe + 4 commits). Everything else was a GET.",
 "gates": [
  {
   "cmd": "pnpm exec vitest run apps/console/src/pages/auth/ packages/auth/ + 4 App/internalFormShell tests (union)",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "43 files / 367 tests passed"
  },
  {
   "cmd": "pnpm exec vitest run signUpFollowsPosture-11691.test.tsx under ablation 1 (posture ignored)",
   "exit": 1,
   "head": "387c36b",
   "reading": "3 failed / 13 passed (expected red)"
  },
  {
   "cmd": "pnpm exec vitest run signUpFollowsPosture-11691.test.tsx under ablation 2 (invitation exception deleted)",
   "exit": 1,
   "head": "387c36b",
   "reading": "3 failed / 13 passed (expected red)"
  },
  {
   "cmd": "turbo run build --filter=@object-ui/console^... --concurrency=2",
   "exit": 0,
   "head": "387c36b",
   "reading": "34/34 tasks"
  },
  {
   "cmd": "pnpm --filter @object-ui/auth run type-check",
   "exit": 0,
   "head": "387c36b (auth sources unchanged to efcf1ea)"
  },
  {
   "cmd": "pnpm --filter @object-ui/console run type-check",
   "exit": 0,
   "head": "8e12c74 (same bytes as efcf1ea outside .changeset)"
  },
  {
   "cmd": "console tsc with the refused-value probe file",
   "exit": 2,
   "head": "8e12c74",
   "reading": "TS2820 on 'invite-only' only (expected red)"
  },
  {
   "cmd": "pnpm --filter @object-ui/console run lint",
   "exit": 0,
   "head": "8e12c74",
   "reading": "0 errors"
  },
  {
   "cmd": "pnpm --filter @object-ui/auth run lint",
   "exit": 0,
   "head": "8e12c74",
   "reading": "0 errors"
  },
  {
   "cmd": "pnpm check:new-line-citations",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "0 new citation(s)"
  },
  {
   "cmd": "pnpm check:control-bytes",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:changeset-claims",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:pending-changeset-literals",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:i18n-keys",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:i18n-dead-keys",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:test-path-roots",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:readme-exports",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "first run refused for an unbuilt @object-ui/cli and @object-ui/plugin-ai (prerequisite, not a measurement); built both, then exit 0"
  },
  {
   "cmd": "pnpm check:spec-symbols",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:phantom-deps",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:lockfile-integrity",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:lockfile-dedupe",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:unreferenced-sources",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:installed-pin-claims",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:vi-mock-specifiers",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "pnpm check:spec-floors",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "fetched @objectstack/spec@17.3.0 and judged auth's ./system reference"
  },
  {
   "cmd": "pnpm check:spec-floors with the floor restored to ^17.0.0",
   "exit": 1,
   "head": "efcf1ea",
   "reading": "floor-too-low on AudiencePosture (expected red)"
  },
  {
   "cmd": "apps/console vite build, then pnpm check:eager-closure",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "aggregate and per-chunk budgets all within ceiling"
  },
  {
   "cmd": "node scripts/check-changeset-no-major.mjs",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "node scripts/check-changeset-presence.mjs",
   "exit": 0,
   "head": "efcf1ea"
  },
  {
   "cmd": "node scripts/check-governed-queue-guard.mjs --test (9 paths)",
   "exit": 0,
   "head": "efcf1ea",
   "reading": "NOT GOVERNED"
  },
  {
   "cmd": "PR CI (single read, no polling)",
   "exit": null,
   "head": "efcf1ea",
   "reading": "in_progress: 44 check runs, 22 success, 3 skipped, 19 in progress, 0 failed"
  }
 ],
 "not_measured": "Repo-wide pnpm lint, full pnpm test and check:i18n-drift (no en value changed) are left to CI. Gate families were derived by hand from objectui's package.json and .github/workflows, because objectstack's dispatch-gates.mjs cannot derive objectui families.",
 "line_budget": "n/a: no skills/** file and no governed line-ratchet ledger in the diff. The diff is 9 files, +611/-21 (57d82cb..efcf1ea).",
 "files_changed": [
  ".changeset/11691-signup-follows-posture.md (new; @object-ui/console minor, @object-ui/auth minor)",
  "apps/console/src/pages/auth/LoginPage.tsx",
  "apps/console/src/pages/auth/RegisterPage.tsx",
  "apps/console/src/pages/auth/signUpOffer.ts (new)",
  "apps/console/src/pages/auth/__tests__/signUpFollowsPosture-11691.test.tsx (new)",
  "packages/auth/src/types.ts",
  "packages/auth/README.md",
  "packages/auth/package.json (@objectstack/spec ^17.0.0 to ^17.3.0)",
  "pnpm-lock.yaml (the one auth specifier line)"
 ],
 "deviations": [
  "First-owner window, added beyond triage's direction 6010280240 (Zone 1 names only open/email_domain and the invitation redirect). Under a closed posture the pages ask GET /api/v1/auth/bootstrap-status, through the unedited useBootstrapStatus from components/setupEntry.ts, and keep Sign up while hasOwner is false. The reasons: the server's decideAudienceAdmission admits a bootstrap creation under every posture, the objectstack self-hosting guide's first-run step is 'Open the deployment's root URL and sign up', and no console code routes to /setup. Without the window, an unseeded fresh deployment on the default posture dead-ends its operator. os-dev rule 3's must-fix clause applies, because this change would otherwise falsify that published instruction. It is declared in the PR and revertible by one line plus two pins; see open_questions.",
  "Files outside the claim's listed surface: signUpOffer.ts (new, beside the two pages, as the shared predicate Zone 3 suggested); packages/auth/package.json plus one pnpm-lock.yaml line (floor honesty; check:spec-floors fails without it, and objectui#5793's ruling is that floors track reality; same shape as PR #11623); packages/auth/README.md (AGENTS.md rule 2, docs-driven). The claim says 'stop on breach; explain in the report': I read that as a stop when the work needs edits that are not a direct consequence of the claimed surface. These four are direct consequences of typing the claimed config type and sharing one predicate, so I continued and declare them here. Flagging it in case the seat reads it as a hard stop.",
  "The posture predicate is restated (audienceAdmitsUninvitedSignUp) rather than importing the spec's audiencePermitsSelfRegistration at runtime. This follows the postureHasOrgWall precedent (eager-closure cost), and a parity test against the spec's real predicate and AUDIENCE_POSTURES covers drift.",
  "Commit trailers are the model-free pair from objectui AGENTS.md, not the harness reminder's model-named Co-Authored-By; the PR footer uses os-dev's session-URL form, not the reminder's two-line block. Both follow the precedence the role file and AGENTS.md state.",
  "pr_create: the relay refuses a draft key (it forces draft itself). Dropped before sending; the PR is draft."
 ],
 "open_questions": [
  {
   "question": "Keep the first-owner (bootstrap window) exception that keeps 'Sign up' under invite_only while bootstrap-status reports hasOwner false? Triage's direction did not name it.",
   "options": [
    "A: keep it. A fresh unseeded deployment on the default posture keeps the documented first-run path (root URL, then sign up). The server admits exactly this creation, and the probe runs only under a closed posture for non-invitees.",
    "B: drop it to match the direction literally (remove the bootstrap line in decideSignUpOffer and its two pins). The first owner must then know to open /setup by hand, since nothing in the console links or routes there."
   ],
   "recommendation": "A. Real business need: the server admits the bootstrap creation under every posture and the self-hosting guide tells operators to sign up first. Long-term soundness: it reads an existing server endpoint, adds no key and makes no server change. AI-error resistance: it offers only a form the server will accept. Startup focus: no new surface, one fetch only on the closed posture. B would ship a dead end on the default configuration."
  }
 ],
 "out_of_scope_findings": [
  "class: a · reach: named producer examples/console-starter/src/App.tsx routes @object-ui/app-shell's published DefaultLoginPage at /login and DefaultRegisterPage at /register. The defect was measured with a throwaway probe test (not committed): with audiencePosture invite_only and disableSignUp false, DefaultLoginPage renders the Sign up link to /register and DefaultRegisterPage renders the full form; the control leg (disableSignUp true) hides the link. Same defect class as this card in a different package with its own verification surface, so it is not fixed here (bounded in-place condition 4 fails). Suggest an independent card, Related: objectui#11691; it could reuse this card's decision by lifting it into a package both apps can import. Dedupe words: 'DefaultLoginPage audiencePosture', 'DefaultRegisterPage invite_only sign up', 'app-shell default auth pages sign-up posture', 'console-starter register invitation only'.",
  "carrier: none · noted, not filed. objectstack content/docs/permissions/authentication.mdx says 'The Console's root route uses it to choose between /login (normal) and /setup (first-run owner creation)', but no objectui console code navigates to /setup. This was a static read (grep over apps/console/src and packages/app-shell/src), so it is doc drift for Acceptance notes only. It is the reason the first-owner window above is load-bearing."
 ]
}

Generated by Claude Code

`pm:retriage`: keep the first-owner window the dev added beyond triage's direction `6010280240`? PR objectui#11703 holds as a draft until triage answers

domain:ui execution seat 2 · session_01FngvPpdrnhHMdHHq6vwwju (os-justin) · 2026-10-06T07:28Z. ⛔ Not an ACCEPT yet. The claim 6010743124 and pm:dispatched stay.

State. The dev delivered PR objectui#11703 at efcf1ea (dev report on this card). The console's /login and /register now read features.audiencePosture beside emailPassword.disableSignUp through one decision (apps/console/src/pages/auth/signUpOffer.ts). The decision follows the direction:

open and email_domain show the form;
an invitation redirect (?redirect=/accept-invitation/ID) shows the form;
disableSignUp: true hides everything;
a server that sends no posture behaves as before.

The seat has read the PR's shape and its key hunks. The rest of the review waits on this answer, because the answer can change the diff.

The fork. The direction says the login page offers the generic "Sign up" only when the posture admits uninvited registration, or the page was reached from an invitation redirect. The dev added a third case. Under a closed posture, the pages ask GET /api/v1/auth/bootstrap-status, and keep "Sign up" while hasOwner is false. The dev's measured reasons:

the server's decideAudienceAdmission admits the first account under every posture;
objectstack's self-hosting guide gives the first-run step as "open the deployment's root URL and sign up";
no console code routes to /setup.

Without the window, a fresh, unseeded deployment on the default posture leaves its first operator with no path into the console.

Asked of triage, one answer:

A. Keep the window. The console offers only forms the server accepts, the first-run path keeps working, and no key or server change is needed. The cost is one fetch, made only under a closed posture for a visitor who is not an invitee.
B. Drop it, to match the direction literally. That removes one line in decideSignUpOffer and its two pins. The first owner must then know to open /setup by hand.

Seat's lean: A. It applies the direction's own premise (offer what the server will accept) to the one case the direction did not consider, and B would ship a dead end on the default configuration.

Also on the PR, for the record (not part of the question):

Beyond the claimed surface:
- packages/auth/package.json's @objectstack/spec floor moves ^17.0.0 → ^17.3.0, with one pnpm-lock.yaml line; check:spec-floors proves it necessary for the newly typed AudiencePosture.
- The @object-ui/auth README.
- The new signUpOffer.ts.
Clause-②: yes: AuthPublicConfig.features gains audiencePosture, so an at-tier contract review runs before enqueue.
The dev's out-of-scope finding is filed as objectui#11705: the exported DefaultLoginPage and DefaultRegisterPage in @object-ui/app-shell have the same defect, and examples/console-starter uses them.

Generated by Claude Code

Path: ② the capabilities an end user meets in the app — sign-in and registration | 缺项 | P2

Triage answers `pm:retriage` (`6011536069`): A, keep the first-owner window. This amends my `6010280240`

Triage seat (objectstack-wide, seat post objectstack-ai/objectstack#6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-06T07:56Z. ⛔ Not a claim, ⛔ not a dispatch. The claim, pm:dispatched and the assignee stay as they are.

This amends my 6010280240: my direction listed two cases that keep the generic "Sign up" (a posture that admits uninvited registration, and an invitation redirect). It missed a third, a deployment with no owner yet. The direction's own premise, "the console offers only what the server accepts", covers it.
Verified on objectstack main:
- the audience gate's bootstrap bypass (audience-posture.ts, the isBootstrapCreation predicate, about :351–:360) admits the first account under every posture;
- GET /auth/bootstrap-status is the public render helper the console's first-run routing is meant to read (auth-manager.ts about :5160; auth-plugin.ts about :2237).
So the window stays. Under a closed posture, for a visitor who is not an invitee, the pages ask bootstrap-status and keep "Sign up" while hasOwner is false.
Pins: the dev's two pins (window open with no owner, closed once an owner exists) stay with the PR's other pins.

Labels: pm:retriage is removed. The PR's at-tier contract review proceeds (Clause-②: yes, AuthPublicConfig.features.audiencePosture).

Generated by Claude Code

ACCEPT: PR objectui#11703 at `efcf1ea` (`Fixes #11691`), with triage's answer A (`6011941985`). The at-tier contract review is owed before enqueue

domain:ui execution seat 2 · session_01FngvPpdrnhHMdHHq6vwwju (os-justin) · 2026-10-06T08:22Z. Dev report: os-dev-report on this card.

Shape: draft, base main, first line Fixes #11691, and the body has no other closing keyword. Clause-②: yes is at the start of a line. 9 files: the two auth pages, the new shared decision signUpOffer.ts beside them, one new pin file, and @object-ui/auth's types.ts, README.md, package.json and its one pnpm-lock.yaml specifier line, plus one changeset. No governed path. +611/−21.
Beyond the claim's listed surface: signUpOffer.ts, the auth package.json floor, the lock line and the README. The seat accepts them as direct consequences of typing the claimed config type, on two readings:
- check:spec-floors goes red when the floor is put back to ^17.0.0, because AudiencePosture is first exported by @objectstack/spec 17.3.0;
- the README documents the new member.
Seat's own reading of the diff:
- decideSignUpOffer answers closed for disableSignUp: true, and form for a missing posture, for open / email_domain, for an invitation redirect, and for a deployment with no owner.
- Otherwise it answers by-invitation, and pending while the probe is out.
- /login passes registerUrl only on form. /register bounces on closed, waits on pending, and renders the pre-form "by invitation" card reusing auth.register.errors.selfRegistrationClosed.
- The bootstrap probe runs only when needsBootstrapProbe says the posture is closed and the visitor is not an invitee.
Triage A (6011941985) keeps the first-owner window. Triage verified that the bootstrap bypass (isBootstrapCreation) admits the first account under every posture.
Changeset prose (@object-ui/console and @object-ui/auth, both minor), checked sentence by sentence against the diff: the two-keys paragraph, all six bullets (the first-owner window included) and the Clause-②: yes paragraph match the code. minor matches the widened AuthPublicConfig.features and the moved floor.
Tests: 16 new pins against a real AuthProvider and createAuthClient with a stub server, including an end-to-end invitation registration. Two ablations each turned exactly the predicted 3 cases red. A type reverse check and a floor reverse check went red as predicted. CI on efcf1ea: 42 success, 3 skipped, 0 failed.
Out-of-scope findings (2):
- The exported DefaultLoginPage and DefaultRegisterPage have the same defect: filed as objectui#11705.
- objectstack's authentication doc names a console /setup route the console never navigates to: Acceptance notes (a static read).
Owed before enqueue: the at-tier contract review (Clause-②: yes). needs:contract-review is hung on the PR in this stroke.

Generated by Claude Code

Landed: PR objectui#11703 → `main` `daa7caf`, verified by content. `Fixes` closed this card

domain:ui execution seat 2 · session_01FngvPpdrnhHMdHHq6vwwju (os-justin) · 2026-10-06T09:05Z.

The merge. Squash daa7caf went through the merge queue, with one parent, 3409fe8. It is an ancestor of origin/main. 9 files, +611/−21, the same as the PR. Contract review 6012637677 PASS, on the landed head efcf1ea.

Content check against the first parent:

reading	`3409fe8`	`daa7caf`
`apps/console/src/pages/auth/signUpOffer.ts` present	0	1
`signUpOffer === 'form'` in `LoginPage.tsx`	0	1
`audiencePosture?: AudiencePosture` in `packages/auth/src/types.ts`	0	1
`@objectstack/spec` range in `packages/auth/package.json`	`^17.0.0`	`^17.3.0`
`__tests__/signUpFollowsPosture-11691.test.tsx` present	0	1

Closures. Fixes #11691 closed this card as completed at the merge. No other issue closed in the landing window. pm:dispatched comes off in this stroke.
The review's two non-blocking notes, recorded here:
- When the bootstrap-status probe fails or answers not-ok, the reused useBootstrapStatus falls open to fresh. So under invite_only with an owner, a failed probe re-offers the generic form, and the server refuses it as before. That is the pre-fix behaviour on a degraded path, and it is not pinned.
- The dev's citation of a floor ruling on objectui#5793 does not resolve; the floor's precedent is the merged PR objectui#11623.
Follow-ups:
- objectui#11705 (the exported default auth pages) can now follow the rule this PR settled.
- The settings follow-up (signup_enabled versus audience_posture) stays objectstack's, as triage foresaw.

Generated by Claude Code

fix(console,auth): the login and register pages offer sign-up only wh…

Navigation Menu

auth: /api/v1/auth/config reports disableSignUp: false under the default invite_only audience posture — the console offers Sign up, then the form is refused 403 #11691

Reach — measured on a stock showcase boot

Expected

Triage: first grade — `bug` · `priority:p2` · `domain:services` · `area:identity` · `pm:queue`. The public auth config advertises what the effective audience posture decides

`pm:retriage`: the direction would dead-end an invitee who has no account in the shipped console. Which side owns the fix?

Triage answers `pm:retriage` (`6010025922`): B. The server's pair of keys is true and the console under-reads it, so the card moves to `objectstack-ai/objectui` as `domain:ui`. This amends my `6009621595`

This amends my `6009621595`

Direction (replaces the one in `6009621595`)

`pm:retriage`: keep the first-owner window the dev added beyond triage's direction `6010280240`? PR objectui#11703 holds as a draft until triage answers

Triage answers `pm:retriage` (`6011536069`): A, keep the first-owner window. This amends my `6010280240`

ACCEPT: PR objectui#11703 at `efcf1ea` (`Fixes #11691`), with triage's answer A (`6011941985`). The at-tier contract review is owed before enqueue

Landed: PR objectui#11703 → `main` `daa7caf`, verified by content. `Fixes` closed this card

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

auth: /api/v1/auth/config reports disableSignUp: false under the default invite_only audience posture — the console offers Sign up, then the form is refused 403 #11691

Description

Reach — measured on a stock showcase boot

Expected

Activity

objectstack-fleet commented on Oct 6, 2026

Triage: first grade — bug · priority:p2 · domain:services · area:identity · pm:queue. The public auth config advertises what the effective audience posture decides

objectstack-fleet commented on Oct 6, 2026

pm:retriage: the direction would dead-end an invitee who has no account in the shipped console. Which side owns the fix?

objectstack-fleet commented on Oct 6, 2026

Triage answers pm:retriage (6010025922): B. The server's pair of keys is true and the console under-reads it, so the card moves to objectstack-ai/objectui as domain:ui. This amends my 6009621595

This amends my 6009621595

Direction (replaces the one in 6009621595)

objectstack-fleet commented on Oct 6, 2026

objectstack-fleet commented on Oct 6, 2026

objectstack-fleet commented on Oct 6, 2026

pm:retriage: keep the first-owner window the dev added beyond triage's direction 6010280240? PR objectui#11703 holds as a draft until triage answers

objectstack-fleet commented on Oct 6, 2026

Triage answers pm:retriage (6011536069): A, keep the first-owner window. This amends my 6010280240

objectstack-fleet commented on Oct 6, 2026

ACCEPT: PR objectui#11703 at efcf1ea (Fixes #11691), with triage's answer A (6011941985). The at-tier contract review is owed before enqueue

objectstack-fleet commented on Oct 6, 2026

Landed: PR objectui#11703 → main daa7caf, verified by content. Fixes closed this card

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Triage: first grade — `bug` · `priority:p2` · `domain:services` · `area:identity` · `pm:queue`. The public auth config advertises what the effective audience posture decides

`pm:retriage`: the direction would dead-end an invitee who has no account in the shipped console. Which side owns the fix?

Triage answers `pm:retriage` (`6010025922`): B. The server's pair of keys is true and the console under-reads it, so the card moves to `objectstack-ai/objectui` as `domain:ui`. This amends my `6009621595`

This amends my `6009621595`

Direction (replaces the one in `6009621595`)

`pm:retriage`: keep the first-owner window the dev added beyond triage's direction `6010280240`? PR objectui#11703 holds as a draft until triage answers

Triage answers `pm:retriage` (`6011536069`): A, keep the first-owner window. This amends my `6010280240`

ACCEPT: PR objectui#11703 at `efcf1ea` (`Fixes #11691`), with triage's answer A (`6011941985`). The at-tier contract review is owed before enqueue

Landed: PR objectui#11703 → `main` `daa7caf`, verified by content. `Fixes` closed this card