Skip to content

Credential Discipline (ops)

How Alex runs credential-touching commands in the RTOpacks ops corpus. Pair with standing-rules.md (EXECUTION-AUTHORITY-LOOSE-USE-01 governs who runs; this doc covers how).

Not to be confused with docs/docs/legislation/credential-policy.md — that is the RTO regulatory document governing trainer/assessor credentialling under the Standards for Registered Training Organisations. This file is the internal-ops policy governing API tokens, OAuth flows, secret handling, and paste discipline.

Last updated: 1 June 2026 (EXECUTION-AUTHORITY-SCOPED-REVISION-01 v2 — broad execution model with one rto-nrt-db carve-out: Alex autonomous on all in-scope work, destructive ops on rto-nrt-db need a Tim nod; wrangler auth is OAuth-only, $CF_API_TOKEN retired). Created 16 May 2026 at EMAIL-SEND-CF-MIGRATION-01 Phase 4 close.

Who runs credential-touching commands

Per EXECUTION-AUTHORITY-LOOSE-USE-01 (broad form, standing-rules.md, active while pre-revenue):

Alex executes autonomously all credential-touching commands within brief-authorized scope, reversible and irreversible. Reports results back; no per-command Tim approval. The execution boundary is the brief's scope.

One carve-out: destructive operations on rto-nrt-db (delete / table-drops / destructive schema migrations / bulk deletes) require a Tim nod (see EXECUTION-AUTHORITY-LOOSE-USE-01; composes with feedback_no_d1_export).

Tim executes in two cases only:

  1. External-account work outside Alex's token scope — Resend, Stripe, Apple Developer admin, GitHub org-admin actions outside gh CLI scope, etc.
  2. Out-of-brief destructive work — anything not authorized by the active brief. Alex surfaces; Tim extends scope or files a new brief; then Alex resumes.

Technical mechanisms in use

These mechanisms make the loose-use rule safe by keeping token values out of places they could leak from:

Wrangler OAuth (the path)

wrangler login is complete; OAuth (admin@rtopacks.com.au) carries the full deploy scope set (workers_scripts / workers_kv / workers_routes / d1 / pages / queues / secrets_store write, zone read) with offline_access (refresh auto-renews). Wrangler ops (secret list/put/delete, deploy, KV/D1/R2 mutations, email_sending config) authenticate via this OAuth-cached token in Alex's local wrangler config; the token value never transits Alex's message context or appears in a command.

This is now the only wrangler auth path. Gotcha: wrangler prefers an env API token over OAuth, so a stale $CF_API_TOKEN in the environment silently shadows OAuth and breaks deploys — keep it unset (removed from ~/.zshrc 1 June 2026).

Scoped CF API token (non-wrangler CF API surface) — currently absent

For CF API work outside wrangler's surface (DNS edits, account-level config, anything not exposed as a wrangler command), the pattern is a scoped token in ~/.zshrc as $CF_API_TOKEN, with $CF_ACCOUNT_ID alongside ($CF_ACCOUNT_ID is non-secret and remains).

Status 1 June 2026: $CF_API_TOKEN was removed from ~/.zshrc — it was the dead/rotated token shadowing OAuth (see Wrangler OAuth above). The env-var-indirection pattern still stands; there is currently no token loaded. Re-provision a fresh scoped token via 1Password when DNS / account-level CF API work is next needed.

Usage pattern (when a token is present): reference the env var in curl calls (-H "Authorization: Bearer $CF_API_TOKEN"), never echo $CF_API_TOKEN, never expand the variable into terminal output that gets captured.

Scope when re-provisioned: DNS edit on rtopacks.com.au + rtopacks.dev plus whatever account-level surface the task needs.

Shell-snapshot caveat

Claude Code's Bash subprocesses use a snapshot of the shell environment captured at session start. Live ~/.zshrc edits don't propagate into already-running sessions.

Workaround in active use: source ~/.zshrc 2>/dev/null prefix on Bash calls that need env vars added after session start.

Future sessions pick up ~/.zshrc changes natively at startup; no workaround needed.

Paste discipline (still applies)

Per feedback_terminal_paste_credential_discipline.md: token values are never literal-pasted into terminal output that gets captured. The OAuth + env-var-indirection mechanisms above are designed to make literal paste unnecessary — they don't override the discipline rule, they remove the need for it in the most common cases.

If a literal token paste happens anyway, treat the token as compromised and roll immediately.

Brief-authoring implication

When Claude (or any brief author) drafts a brief, the default assumption is Alex executes. The brief lists targets and verifications; Alex runs the commands.

The previous default assumption ("Tim runs every credential-touching command, brief lists commands for Tim to copy-paste") is retired while the loose-use rule is active.

Briefs call out Tim-executes steps only where one of the two exceptions applies (external-account work or explicitly out-of-brief destruction), and flag destructive rto-nrt-db operations for a Tim nod before Alex executes them.

This file is the entry point for credential-discipline questions. Related material:

  • EXECUTION-AUTHORITY-LOOSE-USE-01 standing rule — see standing-rules.md § "Operating principles". The full rule text including revisit conditions.
  • OPERATING-CALIBRATION RULE — see standing-rules.md § "Operating principles". The calibration framing that supports the loose-use rule.
  • Token rotation cadence + QB OAuth re-auth pattern — see standing-rules.md § "Operational tripwires" / "QB OAuth token — rolling, not fixed".
  • Paste discipline rule (full text + earning context) — see feedback_terminal_paste_credential_discipline.md in Alex's auto-memory. Earned via 9 May 2026 rtopacks-alex-automation token leak; re-applied during EMAIL-SEND-CF-MIGRATION-01 Phase 3a-dev step 2 (15 May).

Revisit trigger

When the first paying customer comes online, this section returns to the prior stricter form. The trigger is customer-online, not date or revenue. See EXECUTION-AUTHORITY-LOOSE-USE-01 (standing-rules.md) for the full revisit logic.