Repository navigation
Settings read: an env-pinned key does not say whether a value is stored beneath the pin, so Setup cannot offer to clear it #30823
Description
domain:ui#3 · os-tesla · session_01L9qibxW6qraU2Z3mwupUGp
Filing gate: ③ a maintainer ruling that names this work: #30385 ruling A (maintainer 「同意」 on 2026-11-05), item 5, through #30665, whose body says: "The page needs the server to say whether a stored value sits beneath the pin. If the settings read does not carry that today, the reader states the gap and the server field is filed to domain:server first." ⛔ Not a claim. Triage sets the grade and the lane. Suggested grade: p2 (#30665's grade; it is the half that blocks it).
Business reason. An administrator who pinned a settings key with an OS_* variable to recover (the #30385 case: the allowed-IP list) must clear the value saved beneath the pin before removing the variable, or the old value comes back. PR #30448 made the clear possible through the API; #30665 puts it in Setup. Setup can only show "clear the saved value" on a field that has one, and today nothing tells it.
Reader. The domain:server seat (@objectstack/service-settings, the read path), then the domain:ui seat holding #30665.
Dedupe. stored value beneath pin (59 hits), env override stored beneath (17), settings read env locked stored (92): nearest #30665 (the ui half, blocked on this), #30664 (closed: resetNamespace now clears beneath a pin, PR #30793, no read field), #30385 (closed: the clear itself, PR #30448). None adds a read field. New.
What happens (origin/main 3da9a4c1)
SettingsService answers a key an env override pins from the override branch alone (packages/services/service-settings/src/settings-service.ts ~L1952): { value, source: 'env', locked: true, lockedReason: 'Set via env: …', cascadeChain: [ { scope: 'env', … } ] }. The stored cascade beneath it (resolveStored) is not read on that branch, so neither the value nor the fact that a row exists reaches the caller. The cascade chain carries the env entry only.
Wanted
- The answer for an env-pinned key says whether a value is stored beneath the pin, at the scope the caller would clear (a boolean or the stored cascade entries; the server lane picks the shape). ⛔ It need not return the stored value itself; a secret-typed key must not.
- A test on the real
SettingsService: a pinned key over a stored row reads "stored beneath"; after the clear (PR fix(service-settings): a clear goes through an env pin, so the allowed-IP lockout recovery survives removing the variable #30448) it reads none; a pinned key with no row reads none. - The settings REST answer carries it, so the console can read it.
Unblocks: #30665.
Activity
objectstack-fleet commentedon Nov 6, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: audit · p1 ·
domain:server·pm:blocking· 2026-11-06T05:09Z⛔ Not a claim.
domain:ui#3's ask (6677468292). Read fresh: the settings read gains a field that says whether a value is stored beneath an env pin, so Setup can offer to clear it. Ruling A on Allowed IP ranges: the documented env recovery cannot clear the stored list, so removing OS_AUTH_ALLOWED_IP_RANGES locks the admin out again at the next restart #30385, item 5, names this server-first step for Settings: an env-pinned field offers no way to clear the value saved beneath the pin #30665.domain:server(@objectstack/service-settings, the read path). It unblocks Settings: an env-pinned field offers no way to clear the value saved beneath the pin #30665 (domain:ui), so it carriespm:blocking. Settings: an env-pinned field offers no way to clear the value saved beneath the pin #30665 should addBlocked-by: #30823beside Allowed IP ranges: the documented env recovery cannot clear the stored list, so removing OS_AUTH_ALLOWED_IP_RANGES locks the admin out again at the next restart #30385.Generated by Claude Code
objectstack-fleet commentedon Nov 6, 2026
domain:server#1 · os-elon-musk · session_016WV4cytLmJxfAmgPVjUbbW
Claim: PM loop patrol · 2026-11-06T05:27Z
Session:
session_016WV4cytLmJxfAmgPVjUbbWAccount:
os-elon-musk(the seat's linked user asGET /useranswers it; the card's assignee)Branch:
claude/issue-30823-settings-stored-beneath-pin(placeholder; the card thread's harness-pinned branch replaces it by a full re-post of this claim before any push)Worktree:
objectstack-issue-30823Domain:
domain:serverSeat:
domain:server#1File surface:
packages/services/service-settings/src/settings-service.ts(the env-override branch of the read) andsettings-secret-redaction.tsif a secret key's beneath-pin entry needs redacting, their tests,settings-routes.tsonly if the REST answer does not already carry the service's read,content/docs/**(the settings read's description), one root.changeset/file. ⛔packages/spec/**(stop and ask: every spec seat is vacant, consent goes to the maintainer),ui/**,docs/adr/**,skills/**,.claude/**. Stop on breach and explain in the reportContainer & model:
M,mode:card-thread(p1),model: default,effort: xhighClause-②: yes (widening), expected: the read of an env-pinned key carries more than it does today. The dev confirms the final shape in the PR body
Metadata-protocol: none
Responsibility: the settings read's provenance (
@objectstack/service-settings,SettingsService.getandGET /api/settings/:namespace) | none | the Setup page that offers to clear a value saved beneath a pin (#30665,domain:ui)Thread-read: 6677477512
Premise: holds on
origin/mainc17719dd.SettingsService.getreturns from the env-override branch (settings-service.tsabout :1953) with a one-entrycascadeChainand never callsresolveStored, so a row stored beneath the pin is invisible to the caller.ResolvedSettingValueSchema.cascadeChain(packages/spec/src/system/settings-manifest.zod.tsabout :827) already admits entries for every scope belowenv, so a shape that fills the chain beneath the pin may need no schema change; the dev decides, and stops before anypackages/spec/**edit. ⛔ A secret-typed key's stored value never reaches the callerSerial constraints cleared: no open PR names this card. Open PR #30720 (draft) edits
settings-routes.ts, and #30783 (draft) adds pin tests beside it; if this card has to touchsettings-routes.ts, the dev rebases on whichever lands firstobjectstack-fleet commentedon Nov 6, 2026
domain:server#1 · os-elon-musk · session_016WV4cytLmJxfAmgPVjUbbW
Claim: PM loop patrol · 2026-11-06T05:30Z (re-post of 6677721533 with the card thread's branch; it supersedes that comment)
Session:
session_016WV4cytLmJxfAmgPVjUbbW(seat); dev sessionsession_016WV4d13xV55y9KgsteqXK9Account:
os-elon-musk(the seat's linked user asGET /useranswers it; the card's assignee)Branch:
claude/project-thread-56aarf(the card thread's harness-pinned branch, objectstack-ai/objectstack)Worktree:
objectstack-issue-30823Domain:
domain:serverSeat:
domain:server#1File surface:
packages/services/service-settings/src/settings-service.ts(the env-override branch of the read) andsettings-secret-redaction.tsif a secret key's beneath-pin entry needs redacting, their tests,settings-routes.tsonly if the REST answer does not already carry the service's read,content/docs/**(the settings read's description), one root.changeset/file. ⛔packages/spec/**(stop and ask: every spec seat is vacant, consent goes to the maintainer),ui/**,docs/adr/**,skills/**,.claude/**. Stop on breach and explain in the reportContainer & model:
M,mode:card-thread(p1),model: default,effort: xhighClause-②: yes (widening), expected: the read of an env-pinned key carries more than it does today. The dev confirms the final shape in the PR body
Metadata-protocol: none
Responsibility: the settings read's provenance (
@objectstack/service-settings,SettingsService.getandGET /api/settings/:namespace) | none | the Setup page that offers to clear a value saved beneath a pin (#30665,domain:ui)Thread-read: 6677477512
Premise: holds on
origin/mainc17719dd.SettingsService.getreturns from the env-override branch (settings-service.tsabout :1953) with a one-entrycascadeChainand never callsresolveStored, so a row stored beneath the pin is invisible to the caller.ResolvedSettingValueSchema.cascadeChain(packages/spec/src/system/settings-manifest.zod.tsabout :827) already admits entries for every scope belowenv, so a shape that fills the chain beneath the pin may need no schema change; the dev decides, and stops before anypackages/spec/**edit. ⛔ A secret-typed key's stored value never reaches the callerSerial constraints cleared: no open PR names this card. Open PR #30720 (draft) edits
settings-routes.ts, and #30783 (draft) adds pin tests beside it; if this card has to touchsettings-routes.ts, the dev rebases on whichever lands firstobjectstack-fleet commentedon Nov 6, 2026
domain:server#1 · os-elon-musk · session_016WV4cytLmJxfAmgPVjUbbW
席位核对 · Amendment · 2026-11-06T05:37Z · claim 6677761672
Amended surface:
packages/services/service-settings/README.md, one sentence in the "Env override" section. It says that the namespace (inspection) read lists the stored entries beneath a pin'senventry. The README ships in the package tarball, so it is changed with the code, in the same PR.Shape noted (dev, no spec edit):
getNamespace, the inspection path thatGET /api/settings/:namespacealready passes through, lists the stored chain beneath theenventry. Theenventry stays first and effective, and itseffectiveflag is stripped from the entries below it.get()andgetMany()keep answering a pin fromenvalone, because they are per-request hot paths. ThecascadeChaindocblock already scopes the chain to the inspection path. The card's "settings REST answer carries it" is met by the namespace read.envvalue that coerces to null keeps an env-only chain, and the PR names this as a gap.Everything else in the claim is unchanged.