Codify Squad invocation fallback topology

[stone16]

Originating Multica issue: STO-397
Original author: @ryan

Summary

Makes Squad ownership the default issue-entry model, declares a Codex-backed Orchestrator fallback for pre-tool provider failures, and changes the intended evaluator topology to DeepSeek primary plus Codex secondary. The repository now validates those topology rules and includes a reusable Squad Issue contract.

Why

This submits the accepted proposal changes from STO-396. Dogfooding found that a Claude/provider quota failure stopped the Discovery Squad leader before delegated work began, while a Codex reroute succeeded. The proposal therefore needs fallback at the Squad entry/steering layer, while preserving Squad ownership, evidence requirements, and rework accounting.

Approach

Updated the company and operating-model documentation, deployment manifest, every baseline Squad manifest, and the Orchestrator contract. Added fail-closed topology validation for fallback identity, membership, profession, and provider diversity, plus regression coverage for the declared provider strategy and Squad Issue template.

Accepted choice: Keep each issue owned by its Squad, declare a same-profession Codex Orchestrator fallback inside every baseline Squad, and use DeepSeek/Codex as independent evaluator lanes.

Rejected alternatives:

• Keep both evaluator lanes on Grok — this conflicts with the accepted provider strategy.
• Reroute a failed Squad run to a free-floating executor — this loses Squad ownership and the leader authority boundary.
• Implement automatic Multica backend failover in this PR — the accepted scope is repository proposal/config topology only.

Constraint: This repository can declare and validate desired topology, but it cannot implement or deploy Multica platform failover behavior in this change.

How I Tested

End-to-end test cases

Case	Test file:line	What it asserts
Desired topology remains convergent	tests/sync-topology.test.py:321	Runs the full plan/apply/verify desired-state suite
Provider and Squad invocation policy	tests/sync-topology.test.py:291	Verifies the Codex Orchestrator fallback, DeepSeek/Codex evaluator lanes, fallback membership in every Squad, template presence, and wrong-profession rejection
Multica sync desired-state behavior	tests/sync-multica.test.sh:1	Exercises repository sync behavior against its fixtures
PR review routing behavior	tests/pr-sweep.test.sh:1	Exercises PR issue routing behavior after the shared company contract changed

Verbatim test output

$ env -u LC_ALL tests/sync-topology.test.py
PASS: topology desired-state tests

$ env -u LC_ALL bash tests/sync-multica.test.sh
PASS: sync-multica desired-state tests

$ env -u LC_ALL bash tests/pr-sweep.test.sh
PASS: pr-sweep PR issue routing tests

Existing tests

$ env -u LC_ALL bash tests/sync-multica.test.sh
PASS: sync-multica desired-state tests

$ env -u LC_ALL bash tests/pr-sweep.test.sh
PASS: pr-sweep PR issue routing tests

New tests added

• tests/sync-topology.test.py:291 — covers provider intent, every Squad fallback declaration, template presence, and fail-closed rejection of a wrong-profession fallback.

Lint / typecheck

$ git diff --check
<no output; exit 0>

$ cmp -s AGENTS.md CLAUDE.md
<no output; exit 0>

$ python3 -m json.tool deployments/agents.json >/dev/null
$ for f in squads/*/squad.json; do python3 -m json.tool "$f" >/dev/null || exit; done
<no output; exit 0>

$ python3 -m py_compile scripts/sync-topology.py tests/sync-topology.test.py
<no output; exit 0>

$ python3 -c '<local Markdown link resolution check>'
PASS: local Markdown links resolve

Rollback Plan

Revert the merge commit with git revert <merge-commit>. Maximum blast radius is single feature: the repository's proposed Squad/evaluator topology and validation; this PR does not modify live Multica state. Time-to-rollback is under one minute before deployment, or one topology-sync cycle if the desired state is applied later.

Out of Scope

• No live Multica deployment or configuration sync.
• No Multica backend implementation of automatic provider/runtime failover.
• No merge or release action.
• No selection of a specific DeepSeek model where the repository currently uses provider-default model resolution.

[coderabbitai]

Warning

Review limit reached

@stone16, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 21 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 259008e7-a25c-4a20-8eb7-b399ac6ccbaf

📥 Commits

Reviewing files that changed from the base of the PR and between 8f4b3e8 and 659d08f.

📒 Files selected for processing (16)

• AGENTS.md
• CLAUDE.md
• README.en.md
• README.md
• agents/orchestrator/skill.md
• deployments/agents.json
• docs/operating-model.md
• scripts/sync-topology.py
• squads/delivery/squad.json
• squads/discovery/squad.json
• squads/experience/squad.json
• squads/growth/squad.json
• squads/reliability/squad.json
• templates/squad-issue.md
• tests/sync-topology.test.py
• workspace-context.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch sto-396-squad-invocation-fallback

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 659d08f4f8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Include the fallback in Orchestrator content sync

When agents/orchestrator/personality.md changes after this instance is created, scripts/sync-multica.sh --apply still resolves the Orchestrator role to only Orchestrator (agent_targets_for, lines 221–233); unlike Engineer and Evaluator, it never targets Orchestrator-Fallback. Because the topology script seeds instructions only during creation, subsequent content syncs and verification leave the fallback with stale personality instructions, so it may not retain the primary leader's authority and behavior during an outage; include both Orchestrator instances in the default target list while preserving the environment override.

AGENTS.md reference: AGENTS.md:L120-L122

Useful? React with 👍 / 👎.

[stone16]

Verdict: request changes.

Standards

• [P1] The declared fallback is not a deployable/verified routing state. squads/discovery/squad.json:5 (and the other four manifests) introduces fallback_leader, but scripts/sync-topology.py:380-415 only creates/updates the remote Squad's single leader_id; the fallback is synchronized only as an ordinary member. After a primary-provider entry failure, there is no repository-managed transition that can let the fallback assume steering while preserving the same owning Squad. Either constrain the tracked contract to what Multica currently exposes, or implement and fresh-read-verify the real fallback routing state before claiming it.
• [P1] Skill attachment drift is invisible to verify. scripts/sync-topology.py:477-485 checks skill names and agent runtime/model drift, but attach_missing_profession_skills() runs only during apply and only when agent_drift is already nonzero. If the fallback's Orchestrator Skill is removed/disabled while its name/runtime/model remain correct, --verify reports convergence and --apply does not repair it. That leaves the fallback without the same-profession contract the PR relies on.

Spec

The declared tests pass, but they validate manifest membership and provider intent, not either runtime behavior above. Also, the PR's DeepSeek/Codex Evaluator choice has now been superseded by STO-408 (qwen3.8-max-preview via OpenCode); this PR should be closed or split so it does not merge the obsolete evaluator topology.