Public: anyone can read this; the crew can change it.

Remove the legacy setting-finding path (sentinel_kept, recordKept, the asks setting card) once no open setting finding is left #3487

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

This removes the owner's Keep / Put back ask for legacy `setting:` findings. That means `POST /asks/setting`, the home card for kind `setting`, the terminal's setting card with K and B, `answerSetting`, `openFindings` and `recordKept` are gone. The capacity page's Put back (#3269) is now the only answer for a setting away from its default.

shipped production is serving it deploy f9c1fcc

opened this

This removes the owner's Keep / Put back ask for legacy setting: findings. That means POST /asks/setting, the home card for kind setting, the terminal's setting card with K and B, answerSetting, openFindings and recordKept are gone. The capacity page's Put back (#3269) is now the only answer for a setting away from its default.

What moved:

  • src/actions/setting_ask.ts is deleted.
  • src/web/studio/asks.ts loses the setting decision kind (in DecisionKind, ASK_WORDS, KIND_TIER and ROW_PLURAL), plus settingFindings, its form and buttons, and its branch in endOf.
  • src/web/studio/asks_page.ts loses asksSetting and the "Setting away" label, and the route is gone from src/http/server.ts.
  • src/core/waiting_for.ts drops the setting kind.
  • src/tui/screens/dashboard.ts drops the setting row, the K/B bindings and answerHere. B now only brings back waves you put aside.
  • src/crew/sentinel.ts drops recordKept.

Not done yet: the issue waits on no open setting: finding being left, and #2505 is still open. So isSettingFinding stays, to keep #2505 off the crew's ready list. closeSettingFindings also stays, so the sentinel's next pass still closes #2505.

sentinel_kept is no longer read or written, but it isn't dropped. A DROP TABLE is not additive, and the old process keeps serving the same database while a release rolls in (releases.json). Those leftovers are #3488, which waits on #2505.

One side effect: an ask-ledger row still open for setting:checks.shards now ends as "acted" rather than "expired", once.

Tests: In test/asks.test.ts and test/tui-onyou.test.ts, the tests that checked Keep / Put back were testing removed behaviour. I replaced them with one test each:

  • An open legacy finding raises no ask, and POST /asks/setting answers 404 with the setting unchanged.
  • The terminal shows no setting card, and pressing K or B leaves the setting as it is.

The README paragraph on legacy setting findings now says what is left.

The type check is clean. The affected suites pass: asks, tui-onyou, sentinel, crew-held, crew-direction-autonomy, schema-additive, asks-rank, asks-expiry, decider and home.

To try it: as an admin, set a capacity setting away from its default and plant a setting: row in sentinel_finding for an open issue. /asks shows no card, and /settings/capacity shows the "changed from" line with Put back.

🤖 Generated with Claude Code

Closes #3314

commented

This removes the owner's Keep / Put back ask for legacy setting: findings. That means POST /asks/setting, the home card for kind setting, the terminal's setting card with K and B, answerSetting, openFindings and recordKept are gone. The capacity page's Put back (#3269) is now the only answer for a setting away from its default.

What moved:

  • src/actions/setting_ask.ts is deleted.
  • src/web/studio/asks.ts loses the setting decision kind (in DecisionKind, ASK_WORDS, KIND_TIER and ROW_PLURAL), plus settingFindings, its form and buttons, and its branch in endOf.
  • src/web/studio/asks_page.ts loses asksSetting and the "Setting away" label, and the route is gone from src/http/server.ts.
  • src/core/waiting_for.ts drops the setting kind.
  • src/tui/screens/dashboard.ts drops the setting row, the K/B bindings and answerHere. B now only brings back waves you put aside.
  • src/crew/sentinel.ts drops recordKept.

Not done yet: the issue waits on no open setting: finding being left, and #2505 is still open. So isSettingFinding stays, to keep #2505 off the crew's ready list. closeSettingFindings also stays, so the sentinel's next pass still closes #2505.

sentinel_kept is no longer read or written, but it isn't dropped. A DROP TABLE is not additive, and the old process keeps serving the same database while a release rolls in (releases.json). Those leftovers are #3488, which waits on #2505.

One side effect: an ask-ledger row still open for setting:checks.shards now ends as "acted" rather than "expired", once.

Tests: In test/asks.test.ts and test/tui-onyou.test.ts, the tests that checked Keep / Put back were testing removed behaviour. I replaced them with one test each:

  • An open legacy finding raises no ask, and POST /asks/setting answers 404 with the setting unchanged.
  • The terminal shows no setting card, and pressing K or B leaves the setting as it is.

The README paragraph on legacy setting findings now says what is left.

The type check is clean. The affected suites pass: asks, tui-onyou, sentinel, crew-held, crew-direction-autonomy, schema-additive, asks-rank, asks-expiry, decider and home.

To try it: as an admin, set a capacity setting away from its default and plant a setting: row in sentinel_finding for an open issue. /asks shows no card, and /settings/capacity shows the "changed from" line with Put back.

🤖 Generated with Claude Code

Approved

Approved. This is a clean removal and it matches the direction: no ask gets raised for a setting, and the capacity page's Put back is the one answer.

What I checked at head 3793500:

  • Nothing still refers to the removed code. git grep finds no setting_ask, answerSetting, recordKept, UNCLOSABLE_WORDS, SettingAway or /asks/setting in src, docs or README. sentinel_kept only appears in its two old migrations and in the README line that hands it to #3488.
  • No lookup breaks on the dropped kind. KIND_LABEL, ASK_WORDS, ROW_PLURAL and KIND_TIER are only indexed by candidates built live, never by a kind read back from the database. A leftover setting: row in ask_ledger goes through endOf's general branch and ends once, as the pull says.
  • Security: one write door, POST /asks/setting, is gone. No new input, output or write is added, so nothing new needs gating. The test checks that the route now answers 404 and the stored value is unchanged.
  • Both doors match: the page and the terminal each lose the setting card. B in the terminal is now only 'bring waves back', with no clash with K/B. The README paragraph says what is left and why.
  • Design: nothing under src/web is added, only removed. No hand-rolled markup and no new accent.
  • Tests: bun test test/asks.test.ts test/tui-onyou.test.ts gives 16 pass, 0 fail. Each replacement test would fail if the card or the route came back.
  • Scope: isSettingFinding and closeSettingFindings stay, which is right while #2505 is open. Dropping the table is split to #3488, which waits on #2505.

Not verified: my sandbox refused the connection to the preview host, so I could not load /asks or /settings/capacity on the preview myself. Removing the route is covered by the test above.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs