Internal planClerqRe-checked 28 September 2026Prepared for Inder

One lane into production

The tester fixes the bugs he finds using Claude Code. Every fix travels the same lane, and Inder’s approval is the only gate onto the live system. First, the side roads that skip that gate have to close.

≈65pull requests a week are already written by Claude and merged by Inder (4-week average)
4side roads may reach production with no review today
0alarms that tell anyone the live app is broken
Re-checked 28 September

What changed since the first draft

Inder shipped a run of hardening changes between 24 and 27 September. Everything below is checked against Clerq’s main at f522f98b and the official GitHub and Claude docs.

Fixed since 24 Sep

  • Deploys wait for green tests on main25 Sep
  • Only the owner can start deploys and runbooks by hand, @claude included25–26 Sep
  • Infra applies only in a second run that names a reviewed plan24 Sep
  • A code-owners file names the owner on every path25 Sep
  • Dependabot raises dependency updates weekly25 Sep
  • A staging site exists at staging.clerq.nz27 Sep; HTTPS not switched on yet

Still open

  • The old control-plane deploy role still trusts every git tag
  • No environment is confirmed locked to main
  • The Cloudflare and Claude tokens are still repo-level secrets
  • No smoke check, rollback or health alarm after a deploy

New in this check

  • The production deploy role now also trusts the staging environment, and it can roll any service
  • The repo lives on a personal account, so collaborators always get write access and GitHub can’t limit who merges
  • Every owner-only guard trusts one login, Trailblazerai-nz, which is shared
  • The deploy gate should also require a push from this repo, not only a branch named main
  • Playwright’s browser downloads aren’t on Claude’s default sandbox allowlist, so end-to-end tests stay in CI
Fix first

Roads into production

On a personal GitHub account, anyone given access can push a branch that carries its own workflow file, and GitHub can’t stop that. So the roles and secrets themselves must only answer to main. Switch to “After the fixes” to see what changes.

Inder merges a pull request
The intended road: merged into main, then the tests pass again on main
deploy role · after green tests on maindeploy role · main only, after Inder approves
Live appmigrations run first, then the new version rolls out
Intended road
Waits for green tests since 25 Sep. No smoke check or rollback yet.
Inder’s checkpoint
Pull request, Inder’s approval, tests on main, smoke check after.
Anyone given access
pushes a branch that carries its own workflow file
infra environments · not confirmed locked to maininfra environments · main only, read-only plan role
Production AWS accountnear-admin rights (PowerUser)
Open unless locked
The official workflow now checks for the owner; a branch can bring its own.
Closed
The environments accept main only. Planning gets a read-only role.
Anyone given access
pushes a branch whose workflow names the staging environment
production deploy role · also trusts stagingstaging gets its own role · staging service only
Live appthe role can roll any service and run tasks
Open unless locked
Added on 27 Sep along with the staging site.
Closed
The staging and production environments accept main only. Staging deploys use a staging-only role.
Anyone given access
creates a release or tag on any commit
old control-plane deploy role · trusts every tagold control-plane deploy role · deleted
Live appcan push images and roll services
Open, no review
Collaborators can create releases. Nothing in the repo uses this role.
Removed
Role deleted, so tags no longer reach AWS.
Anyone given access
pushes a branch that carries its own workflow file
repo-level secrets · Cloudflare, Claudesecrets inside main-only environments
clerq.nz and the tokenscan publish the website and use the owner’s Claude token
Open, no review
Hand-run website deploys are owner-only now; the secrets are still readable.
Closed
Secrets move into environments that accept main only.
Unverified: read from the repo’s code and GitHub’s docs. GitHub’s own settings haven’t been checked, so the two “unless locked” roads may already be closed. The written plan lists the commands. GitHub’s approval click on environments needs Enterprise on private repos, and Inder’s own infra notes now say the same.
Stages

The stages a tester’s bug goes through

Compare how a bug the tester finds gets fixed today with how it would move through the plan. Press play, then flip the smoke check to “Fails” to see what happens when a deploy goes wrong in each case.

Show
Smoke check
  1. 1

    Ticket

    CLQ-123

    Filed with steps on the demo org.

    Tester
  2. 2

    Claude session

    cloud sandbox

    Failing test first, then the fix and the Python tests.

    Tester and Claude
  3. 3

    PR checks

    claude/clq-123-…

    Tests, end-to-end run, and Claude’s review on request.

    GitHub Actions
  4. 4

    Staging preview

    staging.clerq.nz

    The tester re-checks the bug on fresh synthetic data.

    Inder deploys, tester checks
  5. 5

    Inder’s checkpoint

    review + approve

    Nothing merges to main without his approval.

    Inder
  6. 6

    Deploy

    tests → migrate → roll → smoke

    Starts only after the tests pass on main.

    Automatic
  7. 7

    LiveRolled back

    message to Inderalert to Inder

    A message names the PR; the ticket moves to Done.

    Back to the last good version; Inder is alerted.

    Automatic
Press play to follow CLQ-123 through the tester’s stages.

Staging (staging.clerq.nz) runs the web app only, on fresh synthetic data, and is off outside 07:00–21:00 on weekdays. It has no workers or cloud AI, and email, texts and payments fail closed, so bugs in those areas can’t be checked there. Today only Inder can deploy to it, and a US$360 a month budget alert watches its cost.

Access

Access levels

Who can do what, and what actually enforces it. GitHub and AWS do the enforcing, so the limits hold even if a laptop, a session or a password goes wrong.

The repo lives on a personal account, not an organization

Trailblazerai-nz is a personal GitHub account (“Trail Blazer Labs”), and it’s a shared login. On a personal account every collaborator gets write access, there are no read-only roles, and GitHub can’t restrict who presses merge. GitHub can convert the account into an organization with Inder as owner. The repo keeps its address, so the AWS trust rules keep working, and the owner-only guards switch to Inder’s own login.

People

Can they…InderTesterTester’s Claude sessionWhat enforces it
Read the code Yes Yes Yes Collaborator access
Push branches, open pull requests Yes Yes Its own session branch only Claude’s git proxy only allows the session’s branch
Merge to main (which deploys) Yes Only after Inder approves No Protected main with required approval (needs GitHub Pro on a personal account). “Only Inder presses merge” needs an organization.
Start deploys and runbooks by hand Yes No No Owner-only guards in the official workflow files (25–26 Sep). A branch’s own workflow is covered by locking the environments.
Deploy a branch to staging Yes No, Inder does it No Owner-only staging workflow. A staging-only role would let the tester do it safely.
Create tags, or change workflow files on a branch Yes Yes, can’t be blocked on a personal account No workflow edits Made harmless: the tag role goes, and roles and secrets answer to main only
AWS access Yes, from his Mac No No No credentials issued to him
Production data and secrets Yes No No Nothing shared; secrets move into main-only environments

On each system

GitHub

Owner
Trailblazerai-nz, a shared login
Tester
Collaborator, which always means write access here

Claude

Inder
Owner: org settings, PR review, shared environments
Tester
Member with his own seat

Jira

Tester
Normal project user
Claude
Inherits the tester’s own Jira permissions

AWS

Tester
No access of any kind
Claude
No access; its sandbox has no AWS credentials

Machine identities

  • Production deploy rolenz-auckland-1-ci-deploy
    TodayTrusts main, the production environment and, since 27 Sep, the staging environment. Can roll any service.
    FixLock both environments to main. Give staging its own role that can only touch the staging service.
  • Infra rolenz-auckland-1-ci-infra
    TodayPowerUser. Its workflows are owner-only and apply needs a reviewed plan, but its environments aren’t confirmed locked to main.
    FixLock infra-plan, infra-apply and ops to main. Give planning a read-only role.
  • Old control-plane roleclerq-ci-deploy
    TodayTrusts every git tag. Can push images and roll services. Nothing in the repo uses it.
    FixDelete it, from the Mac (the control-plane state lives there).

Code areas: which bugs the tester may fix

Tester fixes

Normal review
  • Screens and layout
  • Wording
  • Form validation
  • Frontend behaviour

Tester fixes, Inder looks harder

Careful review
  • Backend logic away from data and security
  • API responses and error messages
  • Scheduled jobs that don’t touch client data

Inder only

The tester files the bug, doesn’t fix it
  • Infrastructure, CI and workflows
  • Database migrations
  • The anonymiser and the compliance gates
  • Tenancy, sign-in and billing

The code-owners file already flags CI, infra, migrations, brain/ and security/. Add the anonymiser, the gates, tenancy, sign-in and billing to it, and have CI label any tester pull request that touches them.

Why those areas are off limits

Clerq fails closed on purpose. Many things a tester files as bugs are safety features doing their job: the quarantine holding a message, a gate refusing a draft, a screen showing no rows when no firm is selected. Ask Claude to “fix” one and it will, and the fix becomes a privacy hole.

What the tester is set up with

  • His own GitHub account with 2FA, never the shared login
  • His own Claude seat on a Team plan
  • A shared Claude cloud environment where the Python tests run; end-to-end tests run in CI
  • Jira wired in: Claude reads the ticket, and pull requests show on it
  • A CLAUDE.md in the repo that tells Claude the rules
  • Staging previews of his branches, deployed by Inder for now

Claude’s own settings are seatbelts, not locks. Anthropic’s docs call them “a client-side control, not a security boundary”, and organisation-wide settings would also bind Inder. Keep them light.

Alerts

When something breaks

Deploys now wait for green tests, which stops broken code from shipping. Nothing yet notices when a deploy that passed the tests breaks the live app.

Today

  • The only alerts: an hourly smoke-test email to Inder’s Gmail, GitHub’s failed-run emails, and a cost alert for staging
  • No health alarms. The Terraform says “no CloudWatch alarms” itself.
  • The deploy ends at “service is stable”, which doesn’t mean it works
  • Nothing rolls back on its own

After

  • A smoke check after every deploy, with automatic rollback if it fails
  • Automatic rollback when a new version won’t start
  • Six alarms to email, SMS or Slack server errorsunhealthy serversslow responsescrashed tasksstuck queue messagesdatabase at its limit
  • A message after every deploy that names the pull request
  • Migrations only add things: code can roll back, a schema change can’t
Pushback

Where I’d push back

  • Review work lands on Inder

    He already merges about 65 pull requests a week. The tester saves him finding, reproducing and checking bugs, not reviewing them. Measure it after 2–3 weeks.

  • Can the tester read code?

    If not, Inder is the only real reviewer. Start him on screen, wording and validation bugs.

  • No client data in Jira

    Claude reads the ticket and sends it to Anthropic. A real client name or screenshot breaks the rule Clerq is built on. Demo org and staging data only.

  • Test on staging, not the live system

    On the live system Stripe is in live mode and email really sends. Staging fails closed for both, but it can’t test workers, AI or real sends, so those bugs stay with Inder.

  • Claude’s automatic PR review is priced per review

    US$15–25 each. Switched on for every pull request, it would also review Inder’s, about US$4,200–7,000 a month. Run it on request, on the tester’s pull requests only. See the numbers.

Cost

What it costs

Claude seat for the tester
US$25–125
a month
Standard or Premium. Daily use will probably need Premium.
GitHub Team, if Clerq moves to an organization
US$4
per user, a month
The advertised rate for the first 12 months. It unlocks real access levels.
AWS alarms
Under US$1
a month
The first ten alarms are free.
Claude PR review
US$15–25
per review
On request, for the tester’s pull requests.

Automatic PR review, per month

The difference between reviewing the tester’s pull requests and reviewing every one.

Tester’s pull requests only (example: 10 a week)US$650–1,080
Every pull request (≈65 a week, 4-week average)Cost trapUS$4,200–7,000
Solid bar: at US$15 a review. Pale extension: up to US$25. Reviews a month = pull requests a week × 4.33.
Show as a table
ScenarioPull requests a weekReviews a monthCost a month
Tester’s only (example)1043US$650–1,080
Every pull request≈65281US$4,200–7,000
Rollout

In this order

  1. 1

    Close the side roads

    half a day

    Delete the tag-trusting role, lock the five environments to main, move the secrets into them, protect main.

    Owner-only guards and code owners done
  2. 2

    Give everyone their own login

    an hour, done carefully

    Convert Trailblazerai-nz into an organization with Inder as owner, then point the owner-only guards at his own login.

  3. 3

    Onboard the tester

    2–3 hours

    Accounts, Claude seat, a shared cloud environment, CLAUDE.md, a pull request template, the Jira apps.

  4. 4

    Alarms and rollback

    about a day

    Smoke check and rollback in the deploy, automatic rollback on a failed start, six alarms, deploy messages.

  5. 5

    Staging for the tester

    after HTTPS is on

    Give staging its own deploy role so the tester can preview his own branches without touching production.

There’s no safe shortcut before step 1. On a personal account any repo access is write access, and @claude now answers only the owner. Keep the tester filing tickets until the side roads are closed.

Before starting

Questions for Inder

  • Are the five environments locked to main? That decides whether two of the side roads are already closed.
  • Who can sign in as Trailblazerai-nz? Every owner-only guard trusts that login.
  • Move Clerq into an organization? It’s the only way to get read-only access and “only Inder merges”.
  • How comfortable is the tester reading code? It decides which bugs he starts with.