Skip to content

feat: harden recurring fleet failure guardrails - #33

Open
ruby-dlee wants to merge 14 commits into
mainfrom
fm/fm-guardrail-hardening-g6
Open

feat: harden recurring fleet failure guardrails#33
ruby-dlee wants to merge 14 commits into
mainfrom
fm/fm-guardrail-hardening-g6

Conversation

@ruby-dlee

@ruby-dlee ruby-dlee commented Jul 26, 2026

Copy link
Copy Markdown
Owner

Intent

Close four recurring Firstmate failure modes with code-level guardrails: automatic browser safety in every crew brief, authenticated direct-account spawn preflight, completion-report heading-level tolerance, and harness-correct bare skill delivery.

What changed

  • Every ship and scout brief carries the shared headless browser-safety contract.
  • Direct Claude and Codex launches fail before endpoint creation when the selected account directory lacks usable credentials.
  • Completion reports accept the six ordered required sections at either level one or level two while retaining substantive-body validation.
  • fm-send refuses a harness-incompatible bare installed-skill token and names the correct form without changing the existing popup-settle behavior.
  • Checkpoint watchers retain bounded legacy Agent Fleet session reconciliation so managed secondmates keep provider_session_id for sticky recovery.

Secondmate routing contract

The failing pool-only secondmate check did not expect direct account-directory routing.
It failed before reaching its routing assertions because the test fixture did not contain a valid, uniquely registered secondmate home.

The corrected Behavior coverage now states both documented cases explicitly:

  • a primary secondmate pool alone leaves account routing off and does not activate either Agent Fleet or direct account routing;
  • when secondmate account routing is enabled, launch goes through legacy Agent Fleet and must not write account_home.

No undelivered future contract for direct-account secondmate launch is encoded by this PR.

Verification

  • no-mistakes run 01KYFPN0CSMPKEXR070H75KZDJ completed with review, documentation, lint, push, PR, and CI gates passed; its local broad test step was deliberately skipped because this task's brief did not enable Herdr lifecycle testing.
  • The pipeline and local verification ran focused non-Herdr suites for briefs, account credentials, report headings, skill delivery, secondmate routing, checkpoint reconciliation, continuation fixtures, teardown fixtures, and related regression clusters.
  • The canonical ShellCheck 0.11.0 lint passed locally, in no-mistakes, and in GitHub CI.
  • GitHub CI passed repository invariants, Agent Fleet, shell lint, and the latest no-mistakes-origin policy check.
  • The obsolete failed policy run caused by the temporary signature loss was removed after later policy checks passed.
  • The remaining current code failure is the exact accepted pre-existing Herdr base failure documented below.

Accepted pre-existing CI failure

The Behavior job at current head ab8367593ca1f43d987345541eb33f23f390dc29 reaches:

not ok - occupied release-drifted server was restarted or routed

This is accepted as a pre-existing base failure, not fixed or weakened in this lane:

  • current PR base: 3e597f4f3c093d7210a486c7688fb1f41adc14bd;
  • tests/fm-backend-herdr.test.sh is blob d60fde8d30c6e2f4e601e115d9934c46c1dcb56e at both base and head;
  • bin/backends/herdr.sh is blob abe02947a84aaaff7d2a41f9f72b4a0e064609cc at both base and head;
  • neither Herdr file is among the PR's 35 changed paths.

Run: https://github.com/ruby-dlee/firstmate/actions/runs/30218454744

Initial no-mistakes preflight failure

Before the successful pipeline run, the trusted-main config preflight failed twice because the gate repository had no usable origin remote.
The missing remote was restored and the pipeline then ran normally.
The failure remains worth fixing operationally because it stranded a gate behind an opaque trusted-config error.

First failure:

error: "cannot evaluate disable_project_settings: failed to fetch or resolve trusted default branch \"main\" (refusing to run without reading the trusted config)"

Second failure:

error: "no run started for \"fm/fm-guardrail-hardening-g6\": cannot evaluate disable_project_settings: failed to fetch or resolve trusted default branch \"main\" (refusing to run without reading the trusted config)"

Deployment

No manual service deployment is required.
The guardrails take effect when Firstmate updates to the merged template revision.

Updates from git push no-mistakes

@ruby-dlee ruby-dlee changed the title Harden recurring Firstmate failure guardrails feat: harden recurring fleet failure guardrails Jul 26, 2026
@ruby-dlee
ruby-dlee force-pushed the fm/fm-guardrail-hardening-g6 branch from ce70f6d to b245858 Compare July 26, 2026 19:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant