[BotshareAI]

Summary

Adds the harness: 13 always-loaded core rules, 16 skills, 12 missions, 20 behaviour evaluations and deterministic tools that let Claude Code agents improve OpenAMRobot every day, while people keep safety, decisions and merging. The agents' work covers tests, CI preparation, cleanup, PR reviews, and audits of dependencies, contracts, impact, performance, maintainability and the register. It also adds the decisions.yaml lifecycle:

• every PR declares its Decisions impact;
• the evidence check asks the author when the diff touches register values;
• a change request approved by the platform lead becomes a drafted register PR;
• consumers are updated after the merge.
• Review fixes (54bdd2b): manual dry-run path, contract coordination, coverage wording, read-only evidence, credential wording; evaluations rerun 14 of 14 at 3 of 3.
• Review fixes 2 (fix(harness): enforce publish guard against unsafe commit history and tier bypass #76 by @wikki26 and 008633c): NUL-delimited paths, per-commit history checks, tier ceiling on the net change and on every published commit, test-line removal is tier B, stage 4 requires required checks to run and succeed plus green commit statuses; baseline follows the register at P-03 rev20.2.
• Review fix 3 (549db0f): the stage 4 veto window counts from GitHub's creation time of the harness review comment for the current head, never from the committer date.
• Audit fixes (1 Nov effectiveness audits, runs A and B, both in openAMRobot/audits): hook wrappers and glob command names, Nav2 launch and config and the robot model tier C, verify config tier D, session ignores the checkout's Claude config, bundle scrubbing, register audit egress, budgets from policy, sim-analysis only with a producer, human-held issues never selected, evidence sections before a draft, veto from the comment's last update; starter budget (one rotating audit a week, monthly retro); consumer issues need maintainer confirmation; evaluations E15 to E20, 20 of 20 at 3 of 3.

Nothing runs after this PR merges: the workflows are design files under rollout/workflows/. Activation needs the founder's explicit approval comment on #43 (D-02), given after this PR is reviewed and merged, the behaviour evaluations pass, and a supervised dry run has been read. Closing #43 is not authorization by itself. harness/README.md is the operating manual.

Work package

#43 (AI workflow activation). Related: #59, #69.

Integration Gate

Builds on #69 (daily collector; triage reads its watchdog-daily artifact); no file overlap with #69. Reuses tools/check_decisions.py (loader, applies_to matching, JSON findings), tools/sync_audit_issues.py (audit issues, one ID range per audit) and agent-prompts/push-from-bundle.md. Inherits the 29 Oct external audit and instruction matrix:

• register primary, with paired document updates;
• the E01 to E14 behaviour evaluations as a gate;
• explicit coverage: 15 repositories enrolled, audits private, and openamr, EOD-robot, OpenAMR_UI_dev and OpenAMR_UI_package excluded by owner decision;
• an enforcement checklist per repository before write access;
• no-safe-task as a normal outcome;
• untrusted-input and model-fidelity rules;
• manifest Update README.md #8 and platform-sw #101 as owner-led items.

AGENTS.md and CLAUDE.md are unchanged (shared block v2, @AGENTS.md). Rejected:

• AI review callers in product repositories, because they would need the Claude credential there;
• a shared-rules version bump now, because it would fail the agent-rules check in 14 repositories before Gate A;
• the official Claude GitHub App, whose permissions are broader than needed.

Tests

Ran 421 tests, 0 skipped with python3 -m pytest -q tests (278 on the parent). New: tests/test_harness.py, tests/test_harness_publish.py, tests/test_harness_decisions.py, and from the audit fixes tests/test_harness_hook_wrappers.py, tests/test_harness_merge_veto.py, tests/test_harness_outputs_bundle.py, tests/test_harness_select_overlap.py, tests/test_harness_tier_gaps.py, tests/test_harness_workflow_hardening.py. They cover policy, tiers, coverage, the hook, guard, selection, publish validation, artifact boundaries, the review queue, the merge gate, inputs, output scrubbing, decisions impact, the follow-up, register-sync approval, core-rule loading and the eval suite shape. Behaviour evaluations: 20 of 20 cases passed 3 of 3 runs with claude plugin eval on Claude Code 2.1.312 with the pinned model claude-opus-5-5 (harness/evals/BASELINE.md).

Evidence

Base SHA: 1678735
Head SHA: f4e0837
Tree: 69639b1fea599e734d7c1be2f89aef0c4e3e5a56

bash rollout/verify.sh
  PASS: all detected verification stages (Tests executed: 421 of 421 (skipped 0))
python3 -m pytest -q tests
  421 passed in 102.05s (0:01:42)
python3 tools/check_workflow_policy.py --root .
  result: 0 workflow policy findings
python3 tools/check_decisions.py --decisions decisions.yaml --maintainers maintainers.yaml --validate-only
  decisions: 46 loaded, 41 recorded and scanned, 2 open, 3 superseded (citations scanned)
python3 tools/check_decisions.py --decisions decisions.yaml --maintainers maintainers.yaml --root . --repository .github --changed-files changed.txt
  result: 0 contradiction(s), 0 allowed, scope 183 changed file(s); 49 file(s) not scanned (no decision covers their type or path)
python3 tools/check_public_extract.py --root . --repository .github --changed-files changed.txt
  result: 0 finding(s)
python3 tools/check_agent_rules.py --canonical agent-rules/SHARED_RULES.md --file AGENTS.md
  PASS AGENTS.md (v2)
python3 -c "import yaml;b=yaml.safe_load(open('harness/baseline.yaml'));d=yaml.safe_load(open('decisions.yaml'));assert b['p03']==d['in_force']['source']"
  exit 0

changed.txt is git diff --name-only 1678735b5a3adae5d2fdc989bb29f2344a9538fc f4e08372bc239070491017679c140422c841f0dd.

Dependencies

None added to the repository. The design workflows pin by full commit SHA, each verified with git ls-remote against the official repository:

• anthropics/claude-code-action v1.0.264 8c3fd987fa6a6b2654f69275e323d08207fcd36c (MIT)
• step-security/harden-runner v2.22.3 46b06cea07f9e64621fdf066ba77ac6915163d43 (Apache-2.0)
• ros-tooling/setup-ros 0.7.19 649ef6bcd696da05bc27ceb3fab69d810c0daeab (Apache-2.0)
• actions/checkout v7.0.1 3d3c42e5aac5ba805825da76410c181273ba90b1 (MIT)
• actions/upload-artifact v7.0.2 cf430e030ddbb5b0abf93d22962f4752f3646cd9 (MIT)
• actions/download-artifact v8.0.2 9000827ccba6bdab643e8b6fd33ac0654aef8333 (MIT)
• actions/create-github-app-token v3.3.0 64ab729a6294000f5aa4a4bc0b73d1f32bc45510 (MIT)

Decisions impact

• None: no register value is stated, used or changed.
• Consumer: uses or aligns with these entries, unchanged: NEAR-FIELD-FRAMES
• Change: needs a new or changed decision; change request # (entry: )

Safety impact

The changed files are governance tooling, tests and design workflows in this repository. No robot source, launch file, URDF or collision geometry, motion limit, firmware configuration or interface definition changes, and no changed path matches maintainers.yaml safety_paths (tests/test_harness.py checks this with the evidence check's matching). The harness decides what agents may change on the robot later. So before any activation, two parts need human review: the protected paths and tiers in harness/policy.yaml, and the publish job with its guard.

STATE.md

no change: STATE.md arrived with the main merge; this PR is design-only and changes none of its register, readiness or current-work facts.

Not verified

• No workflow has run on GitHub; all four are design files or examples.
• The harden-runner endpoint list is unmeasured; activation starts in audit mode for one week.
• Artifact download through the API redirect, and the default GITHUB_TOKEN reading other public repositories from Actions.
• Workload identity federation with the Claude Console (configured by inputs, not exercised).
• Steps after the agent in the agent job are not a security boundary on hosted runners (sudo). The real boundaries are the publish job's recomputed guard and a short-lived credential. Test counts reported by the agent job are advisory; the PR's own CI is the test gate.
• Repository rulesets and required checks (enforcement checklist in harness/README.md, confirmed per repository by a person).
• The Decisions impact rule warns until each repository requires it; tracked in the issue linked below.
• The stage 4 required check names (quality/test, quality/pr-evidence) must match each repository's real check names before stage 4; the App needs Commit statuses read for stage 4.

AI disclosure

Claude Code drafted and tested every file in a session directed by the platform lead. It ran two independent code review passes and the behaviour evaluations, and fixed every reported defect. This session applied and pushed the prepared change set. A person must read first:

• harness/policy.yaml (tiers C and D, the register-sync exception, coverage);
• harness/CORE_RULES.md;
• harness/claude/hooks/guard_tool.py;
• tools/harness_guard.py and tools/harness_publish.py;
• the publish job in rollout/workflows/harness-run.yml;
• the change to tools/check_pr_evidence.py.

Contribution terms

• Every commit is signed off under the DCO.
• I am covered by an accepted Contributor Agreement.
• Third-party material is identified with source and licence.
• No confidential, personal, credential or export-controlled information is included.
• No partner, customer or private person is named; the application is Use_Case_1.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DZnPERB3or7fhUmLZ1Hads

[BotshareAI]

Tracking issue for the "Decisions impact rule warns until each repository requires it" item under Not verified: #71

---

Generated by Claude Code

[panthera-momagdii]

Reviewed head 50ff826, focusing on policy.yaml, CORE_RULES.md, guard_tool.py, harness_guard.py, harness_publish.py and the publish job. Also checked the merge gate, relevant test coverage and the check_pr_evidence.py diff.

The design-only rollout and separate founder approval on #43 must stay unchanged. This review does not authorize activation.

Requesting changes for three reproducible gaps in the final guard/publish boundary:

1. Git-quoted filenames bypass the protected-path classification.
2. Removing an existing assertion still passes as tier A, despite the tier-A no-test-line-removal condition.
3. A secret-like value committed and then removed is missed by the net-diff scan, although the original commits remain in the bundle and branch that get published.

Inline comments include reproduction details and suggested regression coverage. Please fix these before approval and rerun the guard/publisher tests, including negative cases.

Validation performed: isolated local Git fixtures using byte-verified copies of harness_guard.py and harness_lib.py from this head, with the corresponding path-tier, dependency, mission-exception and safety-path policy entries copied into a test fixture. A safe new test passed and an ordinary protected harness file failed, as expected. All three unsafe fixtures unexpectedly returned PASS. Synthetic secret-pattern text only; no real credentials and no GitHub pushes were used in these tests.

The Repository quality workflow is green. The full upstream 353-test suite and live workflow/agent execution were NOT RUN in this review. No activation, variable changes or merges performed. AI-assisted review.

[panthera-momagdii]

[P1] Parse changed paths with NUL delimiters before applying policy

git diff --name-status quotes paths containing tabs, newlines and, by default, non-ASCII bytes. Splitting the display output leaves the surrounding quotes and escapes in path, so tier_of() is not checking the real pathname. Reproduced with a signed commit adding harness/probe\t.md (a literal tab in the filename): the actual path is tier D, but the guard returns PASS / tier B with files containing the quoted representation. This defeats the publish job's protected-path check even though an ordinary harness/probe.md is correctly rejected.

Use --name-status -z and parse the NUL-delimited status/path records without display quoting. Make diff/stat parsing consistent, or reject unsupported path characters explicitly. Add regression cases for tab, newline and non-ASCII names under protected directories.

[panthera-momagdii]

[P1] Enforce the tier-A restriction on removing existing test lines

Only removed test function names are rejected here. Removing the sole assert from an existing test while keeping its def test_... and a harmless assignment returns PASS / tier A; supplying unchanged before/after executed-test counts also passes. I reproduced that exact case. This violates policy.yaml tier A's condition that no line is removed from an existing test except a rename/move. harness_merge_gate.decide() rechecks file tiers, not this diff condition, so the deterministic gate still treats the weakened test as eligible for stage-4 automatic merge if the other gates pass.

Reject assertion/test weakening and enforce the stated removal rule. At minimum, changes that cannot be demonstrated to be pure renames/moves must not retain tier-A automatic-merge eligibility. Add a regression test that removes an assertion without removing or renaming the test function.

[panthera-momagdii]

[P1] Validate all history that will be published, not only the final tree diff

per_file comes from the net base..HEAD diff, while the later per-commit loop only checks DCO sign-off. The workflow bundles the original commit range and Publisher.push_bundle() pushes the candidate branch without squashing. Reproduced: commit synthetic text that matches this SECRET regex, then remove it in a second signed commit and add a harmless test. The guard returns PASS / tier A, but the synthetic value is still reachable in the bundle's commit history. The same gap applies to protected-path edits that are reverted before HEAD.

Before publishing, scan every newly reachable commit/blob that will be transferred for secrets and forbidden changes, or reconstruct a fresh commit from the validated net change on the trusted base and publish only that sanitized history. Include an add-then-remove secret fixture and an edit-then-revert protected-path fixture. No real credential was used in this reproduction.

[panthera-momagdii]

Focused security/governance review of #70 at head 50ff826, covering harness/policy.yaml, CORE_RULES.md, the PreToolUse hook, tools/harness_guard.py, tools/harness_publish.py, the publish job in rollout/workflows/harness-run.yml, and the stage-4 merge gate.

[P2] Enforce the selected task's tier ceiling in the deterministic publish guard. harness_select.py sets a selected issue's tier to A or B and harness/missions/build.md calls it a ceiling. The publish job passes it as --max-tier. However, in harness_guard.py, if TIER_ORDER[tier] > TIER_ORDER[args.max_tier] only appends a note, not a failure: a selected tier-A issue can produce a tier-B source change, get guard PASS, and be published as a draft PR. The stage-4 merge gate independently rechecks file tiers, which prevents this from automatically merging, but it does not enforce the earlier one-issue/one-scope authoring boundary. Please add a guard failure when the actual tier exceeds --max-tier, and regression tests for A->B rejection and permitted A->A/B->B. Keep the human escalation path instead of silently upgrading the task scope.

Other boundaries inspected: tier C/D path matching, separate publish-job guard and bundle-base check, bot-author review-marker checks, and stage-4 file-tier recheck. No workflows were activated. I did NOT run the 353-test suite, hook evaluations, supervised dry run, GitHub publish, or hardware; this is source-derived and needs verification before activation. Keep #70 draft, and preserve founder approval on .github issue #43 plus a distinct activation PR. AI-assisted review.

[BotshareAI]

Review fixes pushed in 54bdd2b. All five points accepted.

1. Dry run. With HARNESS_PUBLISH unset, a run started by hand runs any mission whatever HARNESS_STAGE says and publishes nothing; scheduled AI runs are skipped. Stage gates apply only when publishing. policy.yaml now defines stage 0. Both publish steps need HARNESS_PUBLISH=true and the route's dry_run=false. The route step is executed by tests/test_harness.py::RouteGateTest (triage, build and review at stages 0 and 1 as dry runs; gates enforced when publishing); those tests fail on the previous workflow.
2. Contracts. Core rule 5 and the contracts skill: one approved contract change request drives one PR per affected repository, each linking the request, merged in order: interface package first and backward compatible, then consumers, then removal of the old form. The shared rules block (AGENTS.md "Contracts") still says "one PR"; that wording goes into shared rules v3 through the retro, since it changes every repository.
3. Coverage. Core rule 12, policy.yaml and the README: every repository has one disposition (enrolled, private, excluded). Excluded repositories are named as excluded, never as clean or unscanned. The daily digest now ends with a deterministic coverage line (private repositories are never named).
4. Read-only work. Core rule 13: the revert test applies to code changes; review, audit, analysis and triage change no file and report the files read, the commands run and NOT RUN for the rest.
5. Credentials. README: federation credentials expire within the hour; a Console API key is spend-limited but long-lived, so rotate it quarterly and revoke it on any suspicion.

Behaviour evaluations rerun after the rule changes, model claude-opus-5-5: 14 of 14 at 3 of 3 runs (harness/evals/BASELINE.md). Tests: 362 passed.

[panthera-momagdii]

Follow-up review of the new head 54bdd2bb253df881901c3daf626acdf1034043a4 against previously reviewed 50ff82690ea3a0987bd00712177c8fb9a554acd9. COMMENT only, not approval or authorization to activate.

The incremental commit addresses the separate governance/dry-run feedback: the manual route now reports dry_run, allows supervised triage/build/review independently of publishing stage, and both publish paths require HARNESS_PUBLISH=true and dry_run=false before --apply. I inspected the changed workflow, policy.yaml, core rules, publish code, route tests, the current hook/guard/merge gate, the shared AGENTS.md rules, and prior review threads. The hosted Repository quality quality/test job 124097061558 passed 362 tests. NOT RUN locally: harness tests, live dry runs, publishing, or activation. The described behaviour is source/CI evidence, not a live deployment test.

The prior security change requests are not resolved by this commit. tools/harness_guard.py is unchanged: the earlier three reproduced P1 findings (Git-quoted protected paths; deletion of an existing assertion still qualifying as tier A; secret/protected edits hidden in earlier commits of the published history) and the P2 tier-ceiling note-versus-failure finding still apply. I am not duplicating their inline reproductions. Please address those checks and add regression coverage before security acceptance.

The AGENTS.md v2 contract wording versus the new one-PR-per-repository core rule is explicitly deferred by the author to shared-rules v3; keep that owner-led reconciliation visible. This is still a design-only draft. No workflow activation without a separate activation PR and Alex's explicit approval on #43, and no automatic-merge or safety acceptance implied.

[wikki26]

[P1] Require executed successful verification before stage-4 automatic merge.

Reviewed head 54bdd2b. tools/harness_merge_gate.py accepts success, neutral and skipped for every check, and its only nonempty requirement is that check_runs contains an object. I ran decide() with an otherwise eligible tier-A PR, a current-head bot PASS marker, an expired veto window, and exactly one completed/skipped check. It returns [] (no rejection reasons), so the candidate is eligible even though no check succeeded or verified anything.

Please require the repository's authoritative verification checks to execute and succeed, while permitting genuinely optional skipped jobs separately. Add all-skipped, all-neutral, missing-required-verifier, and mixed required-success/optional-skip regression cases. The merge path should also inspect the applicable commit statuses/required contexts; its current check-runs-only read is not independent evidence of CLA or other status-based gates. GitHub rulesets remain another boundary, not a substitute for the stated deterministic gate.

Validation: python3 -m pytest -q tests/test_harness.py tests/test_harness_publish.py tests/test_harness_decisions.py: 84 passed on this head. Standalone decide() reproduction returned []. No merges, publishing, dry-run activation or robot execution. The prior quoted-path, weakened-assertion, hidden-history and tier-ceiling requests remain unresolved in the unchanged guard. Keep design-only/draft and preserve separate founder authorization on #43. OpenAI ChatGPT/Codex-assisted review.

[wikki26]

CI/security review for head 54bdd2b (requested by Alex for 2 Nov).

Changes requested — do not activate or treat the green 362-test run as security sign-off. The staged design and separate founder approval on #43 are appropriate, but deterministic guard/publish enforcement still has four release-blocking gaps at this exact head:

1. Protect actual Git filenames, not quoted display strings (tools/harness_guard.py:56-69,82-93). git diff --name-status (and patch headers) quote tabs/newlines. The current split("\\t")/header parsing can tier a protected harness/ filename as B. Use NUL-delimited raw filenames and path-scoped diff/stat parsing; add tab/newline/non-ASCII protected-path regressions.
2. Never auto-publish a weakened existing test as tier A (harness_guard.py:117-132). Existing code checks whether the test_* name disappears, not whether its assertions or test lines are removed. Make deletion of a line from an existing test at least tier B / non-auto-merge (or reject it), and add a fixture removing only the sole assertion.
3. Scan all commits actually pushed (harness_guard.py:117-147, harness_publish.py:201-212). The net base..HEAD scan misses secrets or protected-path edits introduced and then reverted in separate signed commits; publishing the original bundle preserves those objects. Reject unsafe intermediate commits/blobs, or publish only a newly constructed sanitized commit from the independently validated final tree. Test both add/remove synthetic secret and protected-edit/revert fixtures.
4. Enforce the selected issue tier ceiling (harness_guard.py:106-115). Exceeding --max-tier merely appends a note while returning PASS; the publisher subsequently creates the draft PR. Fail the guard when the final actual tier (including dependency-manifest promotion) exceeds the ceiling. Test A→B rejection, A→A and B→B acceptance.

Please rerun the guard/publisher regression suite and the entire harness verifier on the corrected head, retaining separate HARNESS_PUBLISH=true + dry_run=false authorization and the independent founder/activation PR gate. quality/test currently passes, but the four negative security cases above are not established by its existing tests.

Reviewed: policy tiers/blocked commands, 13 core rules, tool hook, publish workflow and credential separation, guard/publisher and existing unit cases at this SHA. NOT RUN: local Git bypass fixtures, model evaluations, supervised dry run, live publish or hardware. This review is not an activation approval.

[BotshareAI]

Review fixes 2 are on this branch (counts in the Evidence block).

@panthera-momagdii, your four guard findings: fixed by @wikki26's #76 (NUL-delimited paths, removed test lines promote to tier B, every published commit scanned for protected paths, secrets, skips and binaries, --max-tier is a failure), and your #76 follow-up (tier ceiling per published commit) by 008633c.

@wikki26, merge gate: decide() now requires the checks in policy.yaml merge_gate.required_checks (default quality/test, quality/pr-evidence) to run and succeed on the head SHA. Skipped or neutral runs never satisfy them; a skipped reusable duplicate and optional skipped jobs are allowed; any other failing or pending run blocks; every commit status (DCO, CLA) must be success, and unread statuses block. Regressions: all skipped, all neutral, missing required verifier, required pending, optional failure, mixed success with optional skips, statuses unread, pending and failed. These fail on 6726eb2.

Also: main merged (register at P-03 rev20.2) and harness/baseline.yaml names P-03 rev20.2, E-01 rev1.6, M-01 rev19.7, BOM 7.14. Still design-only; activation stays with a separate PR and the founder's approval on #43. Please re-review.

---

Generated by Claude Code

[panthera-momagdii]

Focused security re-review of exact head 4b9258d1b67fbbf4b19d9b6a187361038a556c2a (seven commits after previously reviewed 54bdd2b). REQUEST_CHANGES for one new, reproducible stage-4 veto-window defect. This is not approval or authorization to activate.

Previous findings rechecked in source, not repeated as open defects: harness_guard.py now parses NUL-delimited filenames, promotes removed existing test lines to tier B, checks every bundled commit for protected paths/secrets/skips/binaries and tier promotions, and fails when --max-tier is exceeded. harness_merge_gate.py now requires the configured verification jobs to execute and succeed on the exact head and checks status-read failures. I inspected the corresponding regressions, policy, core/shared rules, publish/merge workflows and previous threads. Inspected hosted quality/test run 41325650316: 385 tests executed, 0 failures, 0 skips. I did not run the checked-out test suite locally.

[P1] The 24-hour human veto can expire before a new PR head is pushed. tools/harness_merge_gate.py:113 takes the timestamp from commit["commit"]["committer"]["date"], and line 82 uses that for the 24-hour window. This is a Git commit field, not a trusted GitHub push/PR timestamp; a committer can backdate it using GIT_COMMITTER_DATE. Reproduction: a tier-A PR first appears at 2026-11-01 16:30 UTC with a head whose committer date is 2026-10-29 17:12 UTC. At 2026-11-01 17:12 UTC, with the other gates mocked green, an isolated transcription of current decide() returns no rejection reasons, despite the head being less than one hour old. This makes the intended 24-hour opportunity for human veto disappear, even when exact-head CI and review succeed.

Please measure the veto from a GitHub-controlled timestamp of the current head (or persist its first-seen time), resetting after every push; use a conservative PR updated_at if an exact head-push timestamp is unavailable. Add a regression with an old committer date and a newly arrived head that must stay blocked for the full window.

Evidence boundary: isolated pure-Python transcription and current hosted CI inspected; full local harness, live publish/merge, ROS, Gazebo and hardware tests NOT RUN. Preserve design-only status, separate activation PR, and Alex's explicit approval on .github#43. No changes to source, settings or gates are authorized by this review.

[BotshareAI]

@panthera-momagdii, fixed in 549db0f. The veto clock now starts at the creation time of the harness review comment for the current head SHA: GitHub sets that timestamp, and every push produces a new head and a new comment, so it resets on every push. The committer date is only kept as a lower bound (the later of the two counts), and a head without any GitHub timestamp stays blocked. Regression in tests/test_harness_publish.py::MergeGate::test_veto_window_uses_github_time_not_committer_date: a head with a three day old committer date first seen 42 minutes ago is rejected; it fails on 4b9258d. Tests: 386 passed, 0 skipped. Still design-only; activation stays with a separate PR and the founder's approval on #43.

---

Generated by Claude Code

[panthera-momagdii]

Security re-review of the one-commit change 4b9258d → 549db0f at exact head 549db0f62a2985d91a93f3600049ff8544cf0785. REQUEST_CHANGES, not approval or authorization to activate. I compared the new commit, read the full merge gate, review publisher, regressions, policy, rules, design workflow, previous review threads and exact-head hosted CI. The earlier Git-filename, history-scanning, weakened-test and tier-ceiling findings were addressed on prior commits and are not being repeated.

[P1] The 24-hour veto fix still fails across a PR head update. Publisher.review() in tools/harness_publish.py:227-234 deliberately PATCHes the same bot issue comment on every re-review, replacing its head marker. GitHub retains the comment's original created_at when edited. This gate selects the comment by its current marker but reads its original creation time. Example: a bot comment is created 50 hours ago for old head A; head B is pushed 5 minutes ago; the bot edits that same comment with head=B verdict=pass tier=A; B has a backdated committer date. With otherwise green exact-head checks, start=max(old_comment_created_at, backdated_committer_date) is over 24 hours ago, and decide() returns no veto reason even though B has only existed for 5 minutes. I reproduced this timestamp predicate in an isolated Python fixture, without touching GitHub. The newly added test only uses a fresh comment's created_at and misses the actual publisher/PATCH path. Please use a trustworthy per-head GitHub timestamp: e.g. publish a new bot review comment for every new SHA (update only repeats for the same SHA), or enforce a reliable per-head time that cannot precede the latest push. Add the old-comment/new-head/backdated-commit regression at the publisher-plus-gate boundary.

[P2] Missing status contexts still pass the deterministic gate. At tools/harness_merge_gate.py:79-84, statuses={"state":"pending","statuses":[]} is accepted because the any(... for ... in []) test is false; tests/test_harness_publish.py:222 even uses this as the passing fixture. If CLA/DCO statuses are absent, this gate can return eligible with successful check runs. Please reject a missing/pending combined status (or explicitly require the expected CLA/DCO contexts per repository) and test missing/empty and partial contexts. Do not rely solely on external branch rulesets for the documented independent guard.

Evidence inspected, not run by reviewer: hosted Repository quality run 41334766466 at this exact head, quality/test 386 tests, OK; other jobs completed successfully or were optional/skipped. Reviewer-run: isolated veto timestamp fixture; NOT RUN: checked-out full pytest/verify.sh, live harness, actual PR publishing/merge, supervised dry run, ROS/Gazebo/hardware or behaviour evaluations. Preserve design-only rollout, owner reviews and all approval gates. Activation still requires a separate activation PR and Alex's explicit approval on #43.

[panthera-momagdii]

[P1] This created_at is not the current head's first-seen timestamp after the publisher edits its existing bot comment. tools/harness_publish.py:227-234 PATCHes the same comment across head SHAs, preserving its old created_at. A newly pushed, backdated head can therefore inherit an already-expired 24-hour veto window. Repro and recommended per-head regression are in the review summary.

[BotshareAI]

Two independent effectiveness audits of this branch ran on 1 Nov (reports in openAMRobot/audits, branches harness/effectiveness-audit-2026-11-01 and claude/harness-effectiveness-audit-acq0i0). Their patches are merged here (549db0f to f4e0837), with regressions for each: hook bypasses through bash -c, sudo, pushd, find -exec, glob command names and git -c; Nav2 launch and parameter files, the robot model, Gazebo and launch files are tier C; .openamrobot/** and tools/verify.sh are tier D; the agent session no longer loads .claude from the checkout; the output scrubber reads inside change.bundle; the register audit runs behind the egress list; turn and minute limits come from policy; sim-analysis runs only when simulation.nightly names a producer; issues a person holds (assignee or open PR) are never selected; PR evidence sections are checked before a draft opens; the stage 4 veto window counts from the review comment's last update.

Two owner decisions are recorded in policy: budget plan starter (one rotating audit a week, monthly retro, triage 20 turns; a test adds up the stage 1 schedule against weekly_turn_ceiling), and consumer issues from the decision follow-up are needs-human:triage until a maintainer confirms them. Six new behaviour evaluations (E15 to E20) from the audit; the suite is 20 of 20 at 3 of 3 runs with claude-opus-5-5 (harness/evals/BASELINE.md). Tests: 421 passed, 0 skipped. Still design-only; activation stays with a separate PR and the founder's approval on #43. Please re-review.

---

Generated by Claude Code

[panthera-momagdii]

Focused incremental COMMENT re-review of design-only #70 at exact head f4e08372bc239070491017679c140422c841f0dd (11 commits after my CHANGES_REQUESTED review of 549db0f62a2985d91a93f3600049ff8544cf0785). This is not approval, stage-4 authorization, or harness activation.

Resolved on this head: The prior 24-hour veto-window bypass across an edited bot review comment is addressed in source. harness_merge_gate.decide() now uses the later of the matching comment's GitHub created_at and updated_at (plus the commit-time lower bound). Since Publisher.review() PATCHes that comment for a new SHA, its updated_at starts a fresh 24-hour interval. tests/test_harness_merge_veto.py now covers old-created/new-updated/backdated-commit and expiry cases. I also inspected the new hook/wrapper, tier, bundle-scrubbing, selector, workflow and policy regressions; earlier guard defects are not being raised again.

Still open [P2, already reported at 549db0f]: missing commit-status contexts can pass the deterministic merge gate. tools/harness_merge_gate.py still only tests any(s.get("state") != "success" for s in statuses.get("statuses", [])), without requiring a successful combined state or expected CLA/DCO contexts. With statuses={"state":"pending","statuses":[]}, that condition is false. The new veto regression helper even calls decide(..., statuses={"statuses":[]}) and expects no rejection once its veto interval expires. For an otherwise eligible current-head tier-A PR with successful required check runs, this is still an eligible automatic merge despite missing status evidence. Please fail closed on empty/unread/pending combined statuses and enforce applicable required contexts, with empty, partial and pending-status regression cases. This is re-verification of the existing finding, not a new duplicate defect.

Evidence inspected: exact-head GitHub Actions Repository quality run 41358896702 succeeded; its quality/test log shows 421/421 tests executed and passed, 0 skipped, with ros-verifier-smoke passed. The GitHub CLA status for this head reports success; that does not prove the independent merge gate rejects missing statuses on other PRs. The new behaviour-evaluation 20-of-20 / 3-run result is author-reported, not independently reproduced by this reviewer. NOT RUN locally: full verify/pytest, actual harness publishing or merges, live credentials/activation, ROS/Gazebo/hardware. Keep owner security review and all gates. Activation still requires a separate activation PR and Alex's explicit approval on .github#43.

Superseded by later #70 revisions. The filename parsing, test-line removal and published-history findings from this review are fixed on the current head.

[panthera-momagdii]

Focused final security re-review of #70 at exact head f4e08372bc239070491017679c140422c841f0dd. I dismissed my stale older CHANGES_REQUESTED reviews whose findings are fixed and am keeping only the one current blocker below. This is not activation authorization.

Resolved on this head: NUL-delimited path handling, per-commit published-history scanning, test-line weakening/tier promotion, selected-task tier ceiling, and the 24-hour per-head veto timing are addressed in source and regression coverage. Hosted exact-head Repository quality is green; quality/test reports 421/421 passed, 0 skipped; ROS verifier smoke passes; the current PR's CLA status is success.

[P2, remaining fail-closed defect] Missing commit-status evidence can still pass stage 4. tools/harness_merge_gate.py only rejects when statuses is None or when any element of statuses['statuses'] is non-success. For GitHub's valid empty response {'state':'pending','statuses':[]}, any(...) is false, so the deterministic gate adds no status reason. The current regression helper in tests/test_harness_merge_veto.py explicitly calls decide(..., statuses={'statuses':[]}) and expects an empty reason list after the veto period. Therefore an otherwise eligible tier-A PR with successful required check-runs can still be auto-merge eligible when CLA/DCO/other required commit-status contexts are absent entirely.

Please fail closed on empty/pending combined status evidence and require the applicable expected contexts per repository (at minimum the governance/CLA-DCO contexts the design says must be green), with regressions for: empty statuses, combined state=pending, one expected context missing, partial success, and all expected contexts success. Do not rely only on external rulesets for this independent stage-4 guard.

Reviewer RUN: isolated reproduction of the current status predicate: statuses=None rejects; {'state':'pending','statuses':[]} produces no rejection; a failing status rejects. Inspected: exact-head source, merge-gate tests, publisher review path, previous threads and hosted CI. NOT RUN: full local harness suite, live publish/merge, credentials, supervised dry run, ROS/Gazebo/hardware or behaviour evals. Keep the design-only boundary and all human gates. Activation still requires a separate activation PR and Alex's explicit approval on .github#43.