A setting the sentinel finds away from its default is the owner's ask (Keep or Put back), never a crew run #2043

A setting the sentinel finds away from its default now reaches the admin's inbox as one ask with Keep and Put back, and no agent is assigned to it. bun x tsc --noEmit, test/sentinel.test.ts, the test/asks* suites and the schema-additive and migration tests all pass. I did not run the whole suite.

• No crew run. In this tree a setting finding was never urgent, so handOver never assigned it. I added a guard in src/crew/sentinel.ts anyway, and a test that no issue.assigned event follows a setting finding while a budget breach is still assigned. That new test would pass without the guard.
• The ask. There is one ask per open setting: finding, keyed on the setting (setting:<key>) and never grouped with others. It shows the key, value, default, and who set it and when. The code is in src/web/studio/asks.ts.
• Who sees it. It shows only to a forge admin who writes to the repository where the finding was filed. I made it admin-only because changeCapacity already refuses everyone else, so a non-admin would see a button that fails.
• Keep and Put back. Both are POSTs to /asks/setting, handled in src/actions/setting_ask.ts, with the same-origin check and write access. Keep closes the finding with reason dropped and records it in sentinel_kept. Put back calls changeCapacity(key, null), the capacity page's own path with its validation, change record and event, then closes the finding with reason done.
• Only a person's close counts. settingKept now requires that the latest issue.closed event on the finding was made by a person. A close by an agent records nothing. The migration 20261016120000-kept-is-a-person-s deletes sentinel_kept rows whose finding was last closed by an agent, so cells.egress is asked again. A row kept by a person's close or comment stays. Both are tested. The migration only deletes rows, so it is additive.

What I left out

• Setting asks are not part of bulk actions, which are for pulls and parked issues.
• The finding's body text changed to say the owner is asked. I updated the one existing test that asserted the old wording; that test was tied to the text, not to behaviour.
• Existing tests that closed a finding by SQL alone now also append the issue.closed event, since the close has to name who made it.

To try it

• Set a capacity key away from its default for more than a day, such as checks.concurrency.
• Let the sentinel hunt, then open / as an admin and use Keep or Put back on the card.

Closes #2029

All three review points are fixed and pushed. tsc --noEmit is clean, and test/asks.test.ts and test/tui-onyou.test.ts pass. I did not run the whole suite; the forge's check does that.

• Keep had no admin check. answerSetting now refuses any actor who is not a site admin with not_found, before either answer, as changeCapacity does. Agents still get unauthorized.
• Test for the real hole. A new test in test/asks.test.ts makes carol a non-admin who owns the repo holding the finding. Her Keep and Put back both change nothing: the finding stays open, sentinel_kept stays empty and the setting stays at report. The same test then shows the admin's Keep still works.
• Terminal. The On you card lists setting findings for admins. K keeps and B puts back the row under the cursor, through the same answerSetting. Setting rows are left out of mark, close, mute and ship, and the key bar shows K/B only on a setting row. test/tui-onyou.test.ts covers both keys.
• README. The sentinel section now describes the ask, POST /asks/setting, the admin-only rule, the terminal keys, and that only a person's close keeps a setting.

I did not add a hint about K/B to the terminal's help screen. The key bar and the row text already show them.

🤖 Generated with Claude Code

A setting finding can no longer become a crew run. You were right that my earlier guard did nothing: setting findings were never urgent, and the autonomy clock is what starts the run.

• The fix. Autonomy's ready filter now skips any issue that is the finding of a setting:<key> (new src/crew/setting_finding.ts, isSettingFinding). The filter sits beside coveredByRedFix in src/crew/autonomy.ts.
• The test. A new test in test/crew-direction-autonomy.test.ts uses an autonomous repo with a builder on the crew and an open setting:cells.egress finding. Three autonomy ticks leave the finding unassigned, with no issue.assigned event and no run. A normal issue in the same repo is still assigned. I checked that the test fails with the filter stashed and passes with it.
• The old test. I deleted the "never assigned" test in test/sentinel.test.ts, since it passed on main too.
• README. The line now says the autonomy clock leaves the finding out of the crew's ready list, which is true.
• Close result. answerSetting now counts the closes that went through. If none did, it returns forbidden and writes nothing to sentinel_kept. Keep records the value only after a close succeeds.

Not done:

• There is no test for the refused-close path (a mirror, for example); it is covered only by reading the code.
• On Put back, a refused close still leaves the setting changed, because the capacity change happens first. That change is recorded and reversible on the capacity page, but the caller sees forbidden.
• The map's own ready marks are untouched; the filter is only in autonomy's pick.

tsc --noEmit is clean, and the sentinel, asks, tui-onyou and crew-direction-autonomy suites pass (57 tests).

🤖 Generated with Claude Code