tbm-infra-build

name

tbm-infra-build

description

Repo-managed Codex build-lane skill for CI, workflow, Wrangler, and tool-version work in C:\Dev\tbm-apps-script. Use when implementing or verifying changes in `.gitea/workflows`, `wrangler*.toml`, `package.json`, `package-lock.json`, `audit-source.sh`, `.github/scripts`, `.github/tests`, or Cloudflare deploy/test gating. Delegates scope and evidence rules to `C:\Dev\tbm-apps-script\ops\operating-memos\2026-04-22-codex-infra-build-pilot.md`.

TBM Infra Build

This is the Codex build-lane skill for TBM's infra pilot surface.

Load order

1. Read C:\Dev\tbm-apps-script\ops\readme-for-codex-reviewers.md.
2. Read C:\Dev\tbm-apps-script\CLAUDE.md sections on:

• Forge Canon
• Verify-Before-Assert
• Two-Lane Roles

3. Read C:\Dev\tbm-apps-script\ops\operating-memos\2026-04-22-codex-infra-build-pilot.md.

In-scope surfaces

• .gitea/workflows/*.yml
• wrangler*.toml
• package.json
• package-lock.json
• audit-source.sh
• .github/scripts/*.py
• .github/scripts/*.js
• .github/tests/**
• Adjacent fixture directories for CI helpers
• Cloudflare deploy/test gating files in the workflow lane

Before editing

1. Confirm the target is in the Codex pilot lane. If it is GAS, HTML/ES5 UI, or Notion-linked process work, stop and treat it as Claude-lane.
2. Verify repo reality before proposing a change:

• read the exact file
• run the relevant command when a behavior claim depends on runtime output
• capture current command output when the change is about tooling semantics

3. If the task depends on forge state, use the pilot memo's preflight checks before producing a build bundle.
4. Keep .gitea/workflows and .github/workflows distinctions explicit. Do not edit a GitHub-only workflow expecting Gitea to run it.

Validation

Before relying on this wrapper, verify these files exist:

• C:\Dev\tbm-apps-script\ops\readme-for-codex-reviewers.md
• C:\Dev\tbm-apps-script\CLAUDE.md
• C:\Dev\tbm-apps-script\ops\operating-memos\2026-04-22-codex-infra-build-pilot.md

If any are missing, treat the wrapper as stale and say so explicitly instead of guessing.

Adapter rules

• The pilot memo is canonical for scope and evidence rules. Do not fork those rules here.
• The artifact for infra/workflow work is verified code plus captured evidence, not prose about what should happen.
• When external platform semantics matter, use primary docs before asserting behavior.
• Stay in the infra lane. Do not spill into GAS/HTML or governance edits unless LT explicitly expands scope.

Output expectation

• Name the exact files changed.
• Name the verification command(s) run.
• If something could not be verified, state the missing proof surface instead of assuming.