docs: reachableceo wording sweep per 2026-09-09 direct order

House style: the principal identity is named (reachableceo), never 'the founder'. No behavior change. https://projects.knownelement.com/issues/942
2026-09-09 12:43:23 -05:00
parent 627948a98e
commit 0076b4f941
6 changed files with 18 additions and 18 deletions
@@ -7,7 +7,7 @@ description: >
  schema, and verification. Use whenever asked to "stand up" an identity or
  agent, create/fix Cloudron users, wire SSO, debug identity logins or 2FA,
  or store identity credentials — even if the word "provisioning" is not used.
-  Policy-critical: encodes founder rulings #942 (unique passwords, Cloudron-only
+  Policy-critical: encodes reachableceo rulings #942 (unique passwords, Cloudron-only
  accounts, no reachableceo credentials).
 ---
@@ -19,17 +19,17 @@ Bitwarden vault. The Cloudron is the ONLY identity source: never create local
 accounts in Redmine, Gitea, Discourse, or GLPI — the system account comes into
 existence when the identity completes its first SSO login there.
-## Non-negotiable policy (founder rulings — violating these invalidates the work)
+## Non-negotiable policy (reachableceo rulings — violating these invalidates the work)
 1. **Unique password per identity.** One identity, one password, used only for
   its Cloudron account. Shared passwords are banned (Redmine #942).
 2. **Cloudron-only accounts.** System access = SSO first-login. No local
   accounts, no admin-created users in the downstream systems.
 3. **Never use reachableceo credentials.** Items like `creds/gitea-admin`,
-   `creds/gitea`, `creds/redmine` are the founder's personal accounts and
+   `creds/gitea`, `creds/redmine` are reachableceo's personal accounts and
   carry RESTRICTED notes. If an auth test resolves to user `reachableceo`,
-   stop — you are holding the founder's identity.
+   stop — you are holding reachableceo's identity.
-4. **TOTP seeds MUST be stored in Bitwarden** (founder ruling 2026-09-08).
+4. **TOTP seeds MUST be stored in Bitwarden** (reachableceo ruling 2026-09-08).
   Enroll TOTP and write the base32 seed to the vault item in the same
   breath — a seed that is not in the vault is treated as lost, because
   there is no admin 2FA reset on this Cloudron and no other record exists.
@@ -42,9 +42,9 @@ existence when the identity completes its first SSO login there.
 ## Scope check
-Identity stand-up is the COO C2 lane's assigned program (founder directive,
+Identity stand-up is the COO C2 lane's assigned program (reachableceo directive,
 2026-09-08). If your chat runs in another lane (SRE, security, OAM), confirm
-the founder assigned the stand-up to you before executing, or route a ticket
+reachableceo assigned the stand-up to you before executing, or route a ticket
 to the COO C2 lane instead.
 ## Admin lever: Cloudron API token
@@ -70,8 +70,8 @@ seed was lost, then re-enroll with capture. Admin password set:
 ### 0. Prerequisites
 - Vault reachable: `sm get creds/cloudron` works (see references/vault.md).
- For a NEW Cloudron user: the founder generates the invite, or you create the
+- For a NEW Cloudron user: reachableceo generates the invite, or you create the
-  user via the admin token if the founder has authorized self-service.
+  user via the admin token if reachableceo has authorized self-service.
 - A Redmine ticket to record the work (create one if none exists).
 ### 1. Cloudron account (unique password)
@@ -114,7 +114,7 @@ by a real TOTP login (a totpToken in a login is silently ignored for users
 without 2FA — "success" there proves nothing).
 If the identity already has 2FA enforced and no seed exists anywhere: STOP and
-ask the founder. There is no programmatic recovery (verified 2026-09-08).
+ask reachableceo. There is no programmatic recovery (verified 2026-09-08).
 Compute codes offline when needed: `scripts/totp.sh <seed>`.
 ### 3. TOTP enrollment (in the identity's dashboard session)
@@ -155,7 +155,7 @@ success.
  `POST /api/v1/users/<login>/tokens` using the session (requires basic auth
  of the same user for token endpoints).
 - **Discourse**: user API key flow; or admin-generated key if an admin lever
-  is ever provided (none currently is — do not use founder keys).
+  is ever provided (none currently is — do not use reachableceo keys).
 - **GLPI**: My account → API token (personal token); pair with the app token
  from `creds/glpi` (password field) for REST calls.
@@ -18,7 +18,7 @@
 - There is NO admin route to reset another user's 2FA (PUT/PATCH/DELETE on
  `/users/<uid>` 2FA variants all 404; the dashboard UI only offers profile
  self-service enrollment). Consequence: TOTP seeds not captured at
-  enrollment are unrecoverable without the founder.
+  enrollment are unrecoverable without reachableceo.
 - Other useful routes seen in the SPA bundle: `/api/v1/tokens`,
  `/api/v1/oidc/clients`, `/api/v1/groups`, `/api/v1/eventlog`,
  `/api/v1/app_passwords`. Verify behavior at runtime before relying on a
@@ -51,10 +51,10 @@ exist (`coo`). Identity emails follow `tsgstaff-<login>@turnsys.com`.
 - Enrollment is profile self-service ONLY. Capture the base32 seed into the
  vault (`sm setfield "<login> Cloudron" totp_seed <seed>`) at enrollment —
  there is no admin reset and no recovery path.
- Policy RULED (founder, 2026-09-08): TOTP seeds MUST be stored in Bitwarden.
+- Policy RULED (reachableceo, 2026-09-08): TOTP seeds MUST be stored in Bitwarden.
  Enroll 2FA only when the seed is being captured to the vault item in the
  same step. Legacy identities whose seeds were never captured (the whole
-  August batch) are reset-on-sight candidates: founder clears 2FA or hands
+  August batch) are reset-on-sight candidates: reachableceo clears 2FA or hands
  over the seed, then re-enroll with capture.
 ---
@@ -37,7 +37,7 @@ rabbit hole (see #939 correction).
  password across cloudron+gitea+redmine+discourse, and the stored password
  already fails Cloudron auth (401 tested). Shared passwords are banned
  (#942); treat those items as stale until their owning lane remediates.
- Several "admin" vault candidates resolved to the founder's personal
+- Several "admin" vault candidates resolved to reachableceo's personal
  reachableceo accounts (gitea id 3, redmine user 5) and none were admin
  (gitea: 403 "user should be the site admin"; redmine: 403 on /users.json).
  They now carry RESTRICTED notes. The compliant Cloudron admin lever is the
@@ -5,7 +5,7 @@ turn a provisioning change lands:
 | Where | What | How |
 |---|---|---|
-| `TSYSGroupCorporate/TSYSGroupAIOS` `agents/global/AGENTS.md` — "Org chart & agent lanes" | THE canonical operational map (every session loads it via symlink) | branch `coo/…` or lane branch → PR → founder merge |
+| `TSYSGroupCorporate/TSYSGroupAIOS` `agents/global/AGENTS.md` — "Org chart & agent lanes" | THE canonical operational map (every session loads it via symlink) | branch `coo/…` or lane branch → PR → reachableceo merge |
 | `reachableceo/org-buildout` `docs/org-chart.md` | The rendered full-group chart (publishable) | same-turn commit |
 | Redmine provisioning ticket | Per-identity state (pw/2FA/seed/systems) | comment with commit URLs |
@@ -62,7 +62,7 @@
  the API key is stored in the item's password field.
 - Admin surface: `/users.json` lists users (admin only — 403 otherwise).
  Every admin candidate tested in the vault so far is NON-admin (they are
-  all the founder's personal accounts anyway — RESTRICTED).
+  all reachableceo's personal accounts anyway — RESTRICTED).
 ## Shared infrastructure hazard
@@ -1,6 +1,6 @@
 #!/bin/bash
 # Authenticated Cloudron admin API call (compliant lever: api-token service
-# account from vault item creds/cloudron — never the founder's accounts).
+# account from vault item creds/cloudron — never reachableceo's accounts).
 # usage: cloudron-api.sh METHOD /api/v1/PATH [JSON-BODY]
 # body -> stdout; HTTP status -> stderr. Secrets never printed.
 set -euo pipefail