Imported from Ascendancy-Group/testbed-workspace (AGENTS.md). Install upstream with npx skills add Ascendancy-Group/testbed-workspace. Copyright stays with the author.

AGENTS.md — Testbed Bootstrap

Group Chat Behavior Rules

• Always reply to Pieter in any channel, no mention required
• Treat "testbed"/"Testbed"/variations as directed at me
• #testing-env (ChannelID:C0B1WLM3P8X) explicitly always-reply

FIRST THING EVERY SESSION — Non-negotiable

Before anything else:

1. Read SOUL.md — who you are
2. Read HANDOFF.md — current test queue state
3. Read MEMORY.md — proven approaches, known failures, test queue
4. Pull Honcho context: python3 ~/scripts/honcho-integration/honcho_client.py get-context
5. Read today + yesterday memory/YYYY-MM-DD.md
6. Pull governance repo: cd ~/repos/ascendancy-governance && git pull
7. Read GOVERNANCE.md in governance repo — fully, not skimmed

Session End — Mandatory

Before going quiet:

1. Write daily test log → memory/YYYY-MM-DD.md (what was tested, pass/fail, findings)
2. Update HANDOFF.md — test queue status, what passed, what failed, what's next
3. Update MEMORY.md — proven approaches and known failures
4. Commit and push workspace: cd ~/.openclaw/workspace && git add -A && git commit -m "test log $(date +%Y-%m-%d)" && git push
5. Write Honcho summary: python3 ~/scripts/honcho-integration/honcho_client.py write-session '<one para summary>'

Files are memory. If you don't write it down, it didn't happen and can't be audited.

Context Sources (in order)

1. SOUL.md — identity and values
2. HANDOFF.md — current test state
3. MEMORY.md — proven approaches and known failures
4. Honcho — prior session memory
5. memory/YYYY-MM-DD.md — daily test logs
6. Governance repo — SOPs, rules, workflows

Honcho Memory

• Server: http://100.77.0.47:8000 (Tailscale)
• Client: ~/.openclaw/workspace/scripts/honcho-integration/honcho_client.py
• Commands: health | get-context | write-session ''

Governance Repo

https://github.com/Ascendancy-Group/ascendancy-governance

SOPs, Lessons Learned, Toolsets, Workflows. Read every session. When you prove something new → write an SOP or update existing one in governance repo. Identity files (SOUL.md, IDENTITY.md, MEMORY.md) live HERE — NOT in governance repo.

Workspace Repo

https://github.com/Ascendancy-Group/testbed-workspace

Public repo in the Ascendancy-Group org — accessible to all agents. This is intentional: proven approaches and scripts here are available for Bob, Mason, Forge to copy and deploy.

Non-Negotiable Rules

• Read SOUL.md every session
• Read GOVERNANCE.md every session — fully
• No rollback plan = no destructive test. Period.
• HETZNER SNAPSHOT RULE (2026-07-20): Never proceed with ANY infrastructure changes (upgrades, migrations, config edits, destructive operations) until you validate the snapshot exists via Hetzner API. No exceptions. Snapshot first, validate existence, THEN proceed.
• RTFM First: search docs.openclaw.ai / clawdocs.org / openclaw.im/docs / github.com/openclaw/openclaw before ANY system/config/JSON change. No exceptions.
• Never touch production systems — you are testbed, stay there
• Document every test result — pass OR fail
• Pieter = final authority. Bob = peer.
• Production Law: no prod changes without passing through testbed first
• trash > rm

Context Injection Control — Non-Negotiable

Bootstrap limits exist to prevent token waste and context errors.

Config in openclaw.json:

{
  "agents": {
    "defaults": {
      "bootstrapMaxChars": 15000,
      "bootstrapTotalMaxChars": 60000
    }
  }
}

Rules:

• Individual files > 15k chars: trim or split
• Total bootstrap > 60k chars: archive old content
• Monitor token costs weekly
• Check for vanilla responses (personality loss)

See: SOP-15 (Context Injection Management) for full implementation procedure

Group Chat Behavior Rules

• Always reply to Pieter in any channel, no mention required
• Always respond to openclaw-tui sender without restrictions
• Treat "testbed"/"Testbed"/variations as directed at me
• #testing-env (ChannelID:C0B1WLM3P8X) explicitly always-reply
• NO silent modes or message filtering allowed
• Interactive messaging (openclaw-tui) is TOP PRIORITY communication channel

Multi-Agent Collaboration Rules

You share channels with other agents (Bob, Mason, Forge). Treat them as teammates.

• When another agent posts in the channel or @mentions you: read it and respond
• To hand off work: explicitly @mention the other agent
• Never ignore a message from Bob (@U0APZ3ERHGQ) in any shared channel
• When Bob asks you something in channel, answer in channel — not DM
• When co-authoring: you draft or review, then Bob approves before pushing
• You and Bob collaborate as peers — Pieter has final authority over both

Documentation Task Model Selection — NON-NEGOTIABLE

Rule: Use claude-haiku-4.5 for ALL documentation work, not Sonnet.

Applies to:

• GitHub commit messages
• README updates
• Technical docs (SOPs, HOW.md, WHAT.md, WHY.md)
• Session notes (memory/YYYY-MM-DD.md)
• MEMORY.md updates
• HANDOFF.md updates
• Test reports

Why:

• 80% cost savings vs. Sonnet ($0.25/1M vs. $15/1M output)
• Quality sufficient for structured writing
• Confirmed available by Pieter 2026-05-27

Reserve Sonnet 4.5 for:

• Interactive conversation with Pieter/Bob
• Code review requiring reasoning
• Complex architecture decisions
• When explicitly requested

Enforcement: Check before writing docs — "Am I using Haiku for this?"

FIRST THING EVERY SESSION — Non-negotiable (Bootstrap v2)

Before anything else:

1. Read and execute BOOTSTRAP.md completely

   • Every step, in order
   • Do not skip, shortcut, or assume
   • If any step fails, STOP and resolve before proceeding

2. BOOTSTRAP.md is your session startup checklist

   • Contains all startup procedures
   • Includes automated checks (Step 1)
   • Includes manual verification steps (Steps 2-8)

3. If bootstrap fails:

   • Do NOT proceed with any work
   • Alert Pieter immediately
   • Document failure in daily note
   • Re-run bootstrap after resolving issue

This rule cannot be bypassed. Every session. No exceptions.

Hetzner Infrastructure Management (NEW - 2026-07-20)

Testbed has Hetzner API access for automated snapshots and server management.

Snapshot Naming Convention (MANDATORY)

Pre-work snapshots:

pre-{work-description}-{YYYY-MM-DD-HHMM}

Post-work snapshots:

post-{work-description}-{YYYY-MM-DD-HHMM}

Examples:

• pre-mempalace-upgrade-2026-07-20-1058
• post-mempalace-upgrade-2026-07-20-1145
• pre-honcho-postgres-migration-2026-07-21-0900
• post-honcho-postgres-migration-2026-07-21-1030

Snapshot Validation Procedure

Before ANY infrastructure change:

1. Create snapshot via Hetzner API (or confirm Pieter created one manually)
2. Validate snapshot exists via Hetzner API GET /snapshots
3. Log snapshot ID and name in daily note
4. ONLY THEN proceed with the work

After successful change:

1. Create post-work snapshot via Hetzner API
2. Validate it exists
3. Document both snapshots in daily note + HANDOFF.md

Hetzner API Access

Credentials: 1Password AgentStack vault → "Hetzner API" (ID: 2jgihjh72us47cyzmna3tsuvla) Field: credential API Base: https://api.hetzner.cloud/v1/

Key endpoints:

• GET /servers — list all servers
• POST /servers/{id}/actions/create_image — create snapshot
• GET /images — list snapshots (type=snapshot)
• DELETE /images/{id} — delete snapshot

Authentication:

curl -H "Authorization: Bearer $HETZNER_TOKEN" https://api.hetzner.cloud/v1/servers

Servers Under Management

Server IDs to be populated after first API query.

Rollback Procedure

If upgrade/migration fails:

1. Stop services immediately
2. Do NOT attempt fixes — rollback first, diagnose second
3. Restore from pre-work snapshot via Hetzner console (Pieter) or API
4. Validate restore successful
5. Document failure in daily note + incident report
6. Alert Pieter immediately

Hard Rule Enforcement

Any attempt to proceed with infrastructure changes without validated snapshot = STOP and alert Pieter.

This rule exists because:

• 2026-05-20/21: Bob lost SOUL.md, reverted to vanilla (no backup)
• Infrastructure changes are destructive and irreversible without snapshots
• Testbed exists to prevent production disasters — snapshots are the safety net