The card that held four dark settings was split: identity and connectors stay admin-only, the four settings follow the route. This captures that the admin's own view did not move — and says plainly why the population the PR is FOR could not be captured.
22 Sept 2026 · branch p7-actor-view-settings · captured against propflow-stage · at 5379533cad+local
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
Read the identity line on this artifact's stamp before the picture. This capture is an org_admin, and that is NOT the population this PR changes. It is still worth capturing, because this PR restructured the card the admin uses: the Company Name field moved from a two-branch {view ? … : ghost} into a three-branch {!view ? ghost : canManageCompanySettings ? field : null}, and the card's own gate grew a second disjunct. Either edit could have dropped a field for the admin and no unit assertion of mine would necessarily have noticed. The assertions below are that regression check: company identity, all four settings, and the Integrations card are all still on the admin's screen.
What it does NOT prove. An org_admin holds canManageCompanySettings AND holdsWorkspaceSeat, so every one of these strings rendered for this identity before this branch too. Nothing here is evidence that the fix works — it is evidence that the fix broke nothing.
Asserted in the captured DOM — Company · Company Name · Tour Duration · A property can set its own on its page. · Application Link · Talk to a Person · Integrations. Seven strings, in two groups with different jobs. ADMIN-ONLY, and the regression check for this diff: 'Company Name' (the field whose render branch this PR rewrote) and 'Integrations' (the card that must stay behind canManageCompanySettings). THE FOUR SETTINGS: 'Tour Duration', 'Application Link', 'Talk to a Person', and the enabled arm of the Tour Duration helper at OrganizationSettingsShell.tsx:919 — 'A property can set its own on its page.' — which is unreachable when canEditTourDuration is false. For THIS identity that sentence proves only that the admin's control is still live. It is the same string that would prove the fix if it could be captured as a non-admin; see the closing note for why it cannot. Tour Showers / Buffer Between Tours are deliberately not asserted: their block is conditional on a settled, readable tour-showers response from stage, and a string whose absence would mean 'the stage read failed' rather than 'the product is wrong' is the drift this directory's README warns against.
1. A non-admin's Company card — blocked by the identity available here, not by the harness. ui-evidence.ts offers two identities: smoke (a shared platform_admin with no home organization, whose view of these four fields is empty by design — view.isPlatformAdmin hides them) and non-staff, the seeded customer account. scripts/seed-evidence-identity.ts DEFAULTS that account to property_manager precisely so a non-admin screen can be photographed — but the account seeded in this environment (two-orgs-evidence@…, org org_jpco) was minted --role=org_admin, and the script refuses to re-stamp an existing address: "an existing account keeps the role and company it was minted with. Use a fresh EVIDENCE_IDENTITY_EMAIL." Capturing the population this PR is for therefore needs a SECOND seeded stage account at a new address, plus a credential pair the tool currently reads from one fixed env var. That is a change to the evidence tooling and to shared stage state — a separate concern from this PR, and the honest place to say so is here rather than in a silent omission. The non-admin behaviour is asserted instead in organization-non-admin-gate.test.tsx ("a seat-holding non-admin gets the Company card WITHOUT company identity or Integrations", on input#company-name being null) and across the nine cases of company-settings-seat-not-rank.test.tsx.
2. The two rewritten helper sentences — unreachable by construction, which IS the finding. Both read "Your account can't change this company-wide setting." and render only when a canEdit* flag is false while the Company card is visible. After this PR no real caller is ever in that state: OrganizationSettings.tsx computes all four canEdit* flags and the card's holdsWorkspaceSeat gate from the SAME expression, so they cannot disagree, and the one population holding the card without the seat — platform staff — has all four fields hidden by view.isPlatformAdmin. They survive as shell-level state for another caller of OrganizationSettingsShell, a pure view component, and are pinned there by organization-tour-duration.test.tsx and organization-application-link-mode.test.tsx. Photographing them would mean handing the shell props the product never produces — a staged picture, not evidence.