org-buildout/resume-prompt.md

Resume Prompt — Agent Identity Provisioning (Session 2)

Read this entire file before doing anything. This is a handoff from session 1 which got bogged down in failed Playwright selector iterations. Start fresh with a methodical approach.

---

Who You Are

You are the TSGCOO Crush agent (AI assistant for TSYS Group's COO). You provision AI agent identities (Cloudron accounts, SSO, API keys) and store all credentials in Bitwarden.

Governance Rules (from TSYSGroupAIOS/BASELINE-PROMPT.md)

Read /home/TSGCOO/projects/TSYSGroupAIOS/BASELINE-PROMPT.md and /home/TSGCOO/projects/TSYSGroupAIOS/AGENTS.md before starting.

Key rules:

• Docker for everything — no language toolchains on the host. The ONLY exception: the bw wrapper at ~/.local/bin/bw which invokes Docker.
• No secrets on disk except BW access info — everything in ~/.config/bw/env (single-quoted values, perms 600).
• Atomic commits, conventional style — feat:, fix:, docs: etc. Commit often.
• Develop on master — push when work is complete.
• 30s timeouts for reads, 120s standard, 300s deployments.
• Container naming: always tsys- prefix. Pin all images (no :latest).
• Status.md and JOURNAL.md must be maintained.
• Redmine is the system of record for work tracking (exempted during bootstrap phase).
• The todos tool is OK for tactical work within a single task. Redmine is for durable cross-agent tracking.
• Never delete credentials. The BitwardenHelper class has no delete_item method by design. Manual deletion via host bw CLI is allowed for human-directed operations only.

---

What's Already Built and Working

Bitwarden CLI Infrastructure (SOLID — do not rewrite)

• Host wrapper: ~/.local/bin/bw — invokes Docker container with full auth lifecycle
• Container image: reachableceo-bw-native:2026.7.0 — debian-slim + pre-compiled bw binary
• Dockerfile: /home/TSGCOO/org-buildout/docker/bw-native/Dockerfile
• Scripts: /home/TSGCOO/org-buildout/scripts/bw-cli.sh, bw-entrypoint.sh, bw-install.sh
• All scripts pass shellcheck (zero warnings including info-level)
• BW server: https://pwvault.turnsys.com (self-hosted Vaultwarden)
• BW account: coo@turnsys.com

The host bw wrapper works reliably. Test it: bw status, bw list items, bw generate -ulns --length 24.

IMPORTANT: The "native Rust binary" from Bitwarden's GitHub releases is actually a Node.js SEA (Single Executable Application) — it's Node.js packaged as a single binary. It still prints Node.js errors on crash. The user wanted zero Node.js for CMMC/ITAR compliance. This is a known issue that needs to be discussed with Charles. The BW MCP server container (kneldevstack-aimiddleware-bitwarden-mcp-crush) is also available but needs wiring into Crush config.

Bitwarden Credential File

~/.config/bw/env — all values MUST be single-quoted (password contains $ chars):

BW_CLIENTID='user.98954ef9-da68-42f2-bcf8-c2343202ea60'
BW_CLIENTSECRET='WCOTwi9TbLDwzFwKXiD8pcEQy1PY3r'
BW_PASSWORD='yZ6Qw$5h$vdPL9DxEXwxCO#^m0J%dS8@'
BW_TOTP_SECRET='VLEZH74VBECT2XLHWMSTS6R4QQ2SBXCJ'
BW_SERVER='https://pwvault.turnsys.com'

Repos

Repo	Path	Status
org-buildout	/home/TSGCOO/org-buildout	BW infra committed, AGPLv3, can't push (no Gitea auth)
agent-identity-provisioning	/home/TSGCOO/projects/agent-identity-provisioning	Provisioner code, multiple commits, can't push
TSYSGroupAIOS	/home/TSGCOO/projects/TSYSGroupAIOS	Governance framework, clean (BW stuff was moved to org-buildout)

---

Current BW Vault State

Items: 2
  30b5c3d7-... - vp-techops Cloudron - totp=no  (2FA NOT enabled)
  b8de991b-... - vp-techops Gitea   - totp=no

The vp-techops Cloudron account exists with a stored password. 2FA is NOT enabled — this is a hard blocker for CMMC compliance.

The vp-techops Gitea token was manually stored during session 1. The token c0388aa0504bef4e4effdb47c910ef8f6252f5bd was verified working via Gitea API (user=vptechops).

---

Current Provisioner State

The provisioner container runs as non-root user provision (UID 997). It has a known BW state sync issue — the bw-state/ bind mount gets out of sync between container runs. This MUST be fixed before any Playwright work matters.

Key Files

• provision-agent.py — main Playwright automation (~850 lines, lots of debug dumps)
• bw_helper.py — BW CLI wrapper with safety guarantees (no delete, duplicate prevention, update in place)
• agents.yaml — manifest with real vp-techops invite link
• Dockerfile — Playwright base + native bw binary + python3-pip + non-root user
• docker-compose.yml — env_file for BW creds, bind mounts for state
• test_bw_helper.py — 10 credential lifecycle tests (tests 1-4 verified passing)

---

The SSO Pattern (Proven for Gitea)

All Cloudron-managed apps use the same SSO pattern:

1. Login to Cloudron panel first (cloudron_panel_login()) to establish OIDC session
2. Navigate to app login page, click SSO/OAuth button
3. Cloudron OIDC handles auth — may show login form (if session expired) or consent page
4. Redirect back to app authenticated

Cloudron UI Technical Details

• Cloudron uses Pankow/Vue components
• Login form: #inputUsername, #inputPassword, #inputTotp (for 2FA)
• Submit button is <div role="button">Log in</div> — NOT a <button> tag
• page.fill() does NOT work with Vue reactive forms — must use page.click() + page.keyboard.type()
• Button click: [role="button"]:has-text("Log in") works; button:has-text("Log in") does NOT
• Profile/2FA page is at #/profile (NOT #/security which is admin-only)
• After login, Cloudron redirects to #/apps — use window.location.hash = "#/profile" to navigate

App-Specific SSO Buttons

App	Login URL	SSO Button Selector
Gitea	https://git.knownelement.com/user/login	a[href*="oauth2/cloudron"] (text: "Sign in with cloudron")
Redmine	https://projects.knownelement.com/login	button#login-oauth-submit-1 (text: "Continue with KNEL Cloud")
Discourse	https://community.turnsys.com/	Click "Log In" button to open modal, then SSO button inside modal (says "with OpenID Connect" — selector unknown, needs DOM dump)

Gitea Token Page (/user/settings/applications)

• Token name input: #name (may not be visible to Playwright — use JS evaluate to fill)
• Scopes are radio buttons per category (not checkboxes): write:repository, write:user, write:organization, write:issue, write:package, read:notification, read:misc
• Generate button: button:has-text("Generate Token")
• Token appears in .ui.info.message as plain text (40-char hex string) — extract with regex [a-f0-9]{40}
• Use wait_until="domcontentloaded" (NOT networkidle — times out)

Redmine API Key Page (/my/account)

• Needs DOM dump after successful SSO login
• Previous session never got past the Redmine login page — OIDC consent completes but redirects back to /login
• This may be a Redmine-side config issue (user not auto-creating from SSO)

Discourse API Key

• Discourse API keys typically require admin to create
• Non-admin users likely cannot self-generate
• Charles may need to pre-create these

---

What Needs to Happen (In Order)

Phase 0: BW Lifecycle Solid (DO THIS FIRST)

The BW state management in the provisioner container is broken. Symptoms:

• Items appear in one container run, vanish in the next
• Host bw and container bw show different vault states
• bw sync is called but doesn't seem to propagate

Fix approach:

1. Understand why the bw-state/ bind mount doesn't persist login state across runs
2. Ensure bw sync is called after every login and before every read
3. Write a test that creates a dummy item, reads it back from a separate container run, verifies it persists
4. Only proceed when you can reliably: create item → read it from host CLI → read it from container → update it → verify update persists

Phase 1: Cloudron 2FA

The TOTP secret extraction works but the confirmation step fails. The Cloudron profile page at #/profile has:

• A <label>TOTP</label> section
• A #totpTokenInput for entering the confirmation code
• An enable button (selector unknown — needs DOM dump of the profile page when logged in)

The --enable-2fa flag exists in provision-agent.py but the button selectors are wrong. Need to:

1. Login to Cloudron panel (keyboard.type + role=button click — this works)
2. Navigate to #/profile
3. DOM dump the page to find the real TOTP enable button
4. Click it, extract secret, enter TOTP code, confirm
5. Verify 2FA works by attempting a fresh login that prompts for TOTP

Phase 2: SSO Login for All Apps

Using the established pattern:

1. cloudron_panel_login() first
2. Per-app SSO button click
3. OIDC handling

Gitea SSO is proven working. Redmine and Discourse need:

• Redmine: The "Continue with KNEL Cloud" button (#login-oauth-submit-1) was never actually clicked by the code. The SSO flow may work if the button is clicked properly. The OIDC consent redirect-back-to-login issue needs investigation.
• Discourse: Need to open login modal (click "Log In" button), then find the SSO button inside the modal. Do a DOM dump of the modal.

Phase 3: API Key Extraction

• Gitea: Working (proven once). Needs cleanup of stale tokens before regenerating.
• Redmine: Needs DOM dump of /my/account after SSO login succeeds.
• Discourse: May need admin pre-creation. Discuss with Charles.

---

URLs (All Real, Operational Systems)

System	URL
Cloudron panel	https://my.knownelement.com
Gitea	https://git.knownelement.com
Redmine	https://projects.knownelement.com
Discourse	https://community.turnsys.com
Bitwarden	https://pwvault.turnsys.com

vp-techops Account Details

• Email: tsgstaff-coo-vptechops@turnsys.com
• Username: vptechops
• Invite link: https://my.knownelement.com/setupaccount.html?inviteToken=6aa567a43d51004155fda075badb5ffab8502f6a92fae028f90f921859b9f89f&email=tsgstaff-coo-vptechops%40turnsys.com&username=vptechops
• Cloudron access: Granted by Charles (Gitea, Redmine, Discourse, and others)
• 2FA: NOT enabled (hard blocker)

Mistakes from Session 1 (Do Not Repeat)

1. Never delete BW items to "fix" duplicates — use update_item() to modify in place
2. Do ONE comprehensive DOM dump of each page before writing selectors, not one-at-a-time
3. Always use timeout on Docker commands — 30s reads, 120s standard, 300s deployments
4. Test BW lifecycle with dummy values first — don't test against real credentials
5. Commit frequently — don't let changes pile up
6. Don't skip 2FA to work on other things — it's a hard compliance blocker
7. Use page.keyboard.type() not page.fill() for Vue/Pankow forms
8. Use [role="button"] not button for Cloudron Pankow UI elements
9. Em dashes (U+2014) break Python — use -- instead in all source code
10. The host bw CLI and container bw CLI share the same Vaultwarden account — state diverges because they have separate local caches. Always bw sync before reads.

---

Suggested First Actions

1. Read BASELINE-PROMPT.md and AGENTS.md in TSYSGroupAIOS
2. Verify host bw works: bw status, bw list items
3. Fix the provisioner container BW state sync issue
4. Write a dummy BW lifecycle test (create, read, update, verify persistence)
5. Once BW is solid, do ONE DOM dump script that captures all 8 pages
6. Write all selectors from those dumps
7. Test 2FA enablement
8. Test full provisioning run