equaltoai

Drive an adversarial, security-first review of a pull request on your governed github_* surface: ground on the real diff at a pinned head SHA, threat-model the change, sweep it through named security lenses, then attempt to refute every candidate finding before reporting — post the survivors as a COMMENT-only PR review with inline threads. NOT for approving, requesting changes, merging, or gating a PR; NOT a replacement for repo CI, SAST/CodeQL, or human security review; NOT for repositories outside your github_list_repos scope; NOT a whole-repo security audit.

Apply this repository's resolved governance profile and verify it: checksum the parent-staged gov-infra genome, run the repo-local verifier to fresh gov_rubric_report.v1 evidence, and confirm branch/profile consistency — for a software_repo_gov_infra steward at milestone boundaries, before a PR, or when governance evidence is stale. NOT for editing the namespace governance profile (that is operator-level setup-governance-profile) and NOT for a parent verifying a submodule (verify-governance-in-submodule).

Use after plan-roadmap is approved, if the roadmap warrants a tracked GitHub Project at the equaltoai org level. Translates a roadmap document into a Projects v2 kanban board with issues across the affected repos. Follows equaltoai's established project pattern.

Use to walk a merged change through per-stage CDK deploy — `lab`/`dev` → `staging` → `live` — with SSM parameter-export publication, three-step first-deploy coordination with lesser when applicable, and never-timeout on CDK commands.

Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit.

Use for any GitHub operation on equaltoai/lesser-body — branches, commits, pull requests, reviews, issues, comments, checks, orchestrated closeout. Prefer the governed TheoryMCP github_* tools (agent-scoped, attributable as body-theorymcp[bot], policy-gated) over the gh CLI; fall back to gh only for operations TheoryMCP does not expose (PR body read, Projects v2, delete-branch, resolve-thread, releases, workflow dispatch, secrets, gists, gh api, other repos) and say so explicitly.

Use to execute a single milestone (or GitHub Project phase) of work — feature branch off staging, commits per enumerated task, PR review with existing ci / verify, merge to staging. Runs one milestone at a time. Deploys themselves go through deploy-body.

Use after enumerate-changes. Takes a flat enumerated change list and sequences it with dependencies, risks, and a per-stage rollout plan. Produces a roadmap document, not code or project state.

Use when Codex handles GitHub activity for equaltoai/lesser-host and should preserve routed-agent provenance: reading issues or PRs, commenting, reviewing, creating agent-scoped branches, committing bounded file changes, opening PRs, or creating truthful check runs. Prefer the mcp__host_lab__ GitHub tools whenever they can perform the needed operation; fall back to the general GitHub plugin or gh only for capabilities the routed tools do not expose.

Use when a change touches the trust API surface (`/.well-known/*`, `/attestations/*`), instance authentication (sha256(raw_key) matching), attestation shape or integrity, CSP (single-origin enforcement on `web/`), or safety / AI-evidence services. Walks trust posture with rigor; loosening these surfaces is refused without explicit governance event.

Use when building or maintaining host surfaces framework awkwardness — an AppTheory middleware / construct limitation, a TableTheory query-builder friction, a FaceTheory pattern gap (for `web/`). Produces a cleanly-shaped signal for the relevant Theory Cloud framework steward rather than a local patch. host's role as a high-governance, multi-tenant, multi-worker consumer means framework-consumption awkwardness here is scope-evidence for framework evolution under the harder constraints.

Use after plan-roadmap is approved, if the roadmap warrants a tracked GitHub Project at the equaltoai org level. Translates a roadmap document into a Projects v2 kanban board with issues across the affected repos. Follows equaltoai's established project pattern.

Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit.

Use when a change touches the soul registry — Solidity contracts in `contracts/`, on-chain-reaching Go code, off-chain DynamoDB state that mirrors on-chain references, Safe-ready governance payloads, mint-signer key handling, or the soul-namespace contract lesser-soul publishes. Walks contract integrity (Slither + hardhat + solhint), deploy discipline (Sepolia → Safe-ready mainnet), off-chain reconciliation, and governance-coordination.

Use to execute a single milestone (or GitHub Project phase) of work — feature branch off main, commits per enumerated task, PR review with gov-infra verifiers, merge to main. Runs one milestone at a time. Deploys themselves (CDK lab/live, on-chain Sepolia/mainnet, managed-instance rollout) are handled separately.

Use when a user reports a bug, regression, or unexpected behavior in host — control-plane API failure, trust-API instance-auth rejection, provisioning worker failure, soul-registry on-chain mismatch, managed-update step failure, release-verification mismatch, CSP violation, gov-infra verifier failure, CDK deploy issue. Runs before any fix is proposed. Produces an investigation note, not a patch.

Use when building or maintaining sim surfaces framework awkwardness — a FaceTheory SSR / routing / hydration pattern gap, a Svelte 5 rune limitation, an Apollo Client / graphql-ws edge case, a Playwright specifics gap. Produces a cleanly-shaped upstream signal rather than a local patch. sim's distinctive context — agent-first UX + strict CSP + vendored-Greater integration + async public routes + research-sandbox — makes its framework-consumption feedback high-signal.

Use after plan-roadmap is approved, if the roadmap warrants a tracked GitHub Project at the equaltoai org level. Translates a roadmap document into a Projects v2 kanban board with issues across affected repos. Follows equaltoai's established project pattern, often with upstream-coordination issues in sibling repos.

Use when a change touches CSP compliance (inline scripts / styles / event handlers / third-party origins / unsafe-eval) or GraphQL-first discipline (new REST paths, REST leaking into data operations). Walks the dual constraint strict CSP on built bundle + GraphQL-first with REST only for auth. Loosening either is refused without explicit governance authorization.

Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit aligned with sim's milestone-driven rhythm.

Use to execute a single milestone (Mx.y) or GitHub Project phase — feature branch off main, commits per enumerated task, PR with CI gates + required review, merge to main. Runs one milestone at a time. Install to the two dev-stage instances is handled by install-sim-instance.

Use to walk a merged change through `pnpm build` → `lesser client install` against the two dev-stage target instances (`dev.simulacrum.greater.website`, `dev.theory.greater.website`), followed by Browser Live Smoke workflow validation. Respects the FaceTheory manifest (`facetheory.lesser.json`) + runbook discipline + never-timeout on CI.

Use when a user reports a bug, regression, or unexpected behavior — a public route rendering wrong, a workflow panel failing, a vendored Greater component misbehaving, a GraphQL query returning unexpected shape, a Playwright test flaking, a CSP violation, a deploy / install anomaly, or an LLM-bot-account / research-sandbox issue. Runs before any fix is proposed. The first structural question is always "is this upstream?"

Use after enumerate-changes. Takes a flat enumerated change list and sequences it with dependencies, risks, and an install-rollout plan across the two dev-stage target instances (simulacrum + theory). Produces a roadmap document, not code or project state.

Standardize “high-risk domain” engineering work (finance, healthcare, regulated data) by producing a versioned rubric, milestone roadmap, controls matrix, and evidence plan. Use when planning or auditing systems that handle sensitive data (CHD/SAD, PHI, PII, secrets) or need compliance-oriented hardening (e.g., PCI DSS, HIPAA, SOC2) with measurable verification and CI regression gates.