chore(issues): close #170, and correct #309 to partially delivered

docs/branch-review-records/20b22bab9c03df1ef75e5fc68a4e23226d261c700a10fb4113feca85edc6de57.record.md

@@ -0,0 +1 @@
+| 2026-08-13 | claude/close-filter-rollout-rows | b7ac0f244b128494aa564cd3e300fe673b2b6d2b | close ledger rows #170 and #309 after verifying the filter contract rollout shipped | PR #1925 opened; docs-only. Both rows verified DELIVERED by content on main 2d27039, not PR state: services (service-facets.ts, scope segment on a scope URL param, quick filters evicted to composer suggestions), factsheets (SegmentedControl + counts, no eviction needed - the claim that its presets discarded the query was measured false), therapy-compass (filter-sheet.tsx deleted, converged #1885/#1889), documents (converged #1910 with meterContent/footerOverride); #309 dense tier now in the shared sheet, ported up from documents by PR F rather than duplicated. Also recorded: I first wrote canonical edits via scripts/outstanding-issues.mjs and check:ledger-write-discipline correctly rejected it - npm run issues:done routes through ledger-inbox.mjs, the two entry points are not interchangeable | check:ledger-write-discipline passed for 2d270392f9cf..HEAD; check:outstanding-issues passed 310 rows 114 open 196 archived no ids deleted from base; prettier --check on the two inbox JSON files passed; each mode claim re-grepped against main before writing |

docs/outstanding-issues-inbox/4944d2d8-69b6-479c-b0bd-a977494a74fb.json

@@ -0,0 +1,13 @@
+{
+ "version": 1,
+ "id": "4944d2d8-69b6-479c-b0bd-a977494a74fb",
+ "createdOn": "2026-08-13",
+ "action": "add",
+ "payload": {
+ "pri": "P2",
+ "type": "issue",
+ "summary": "check:ledger-write-discipline reports a pass when run against an uncommitted working tree",
+ "detail": "Found 2026-08-13 while closing #170/#309. The gate compares a committed range (it reported `Ledger write discipline passed for 2d270392f9cf..HEAD`), so when the ledger edit is still unstaged or uncommitted the range is empty and it prints a pass having evaluated nothing. I edited docs/outstanding-issues.md directly, ran the gate, saw green, and only discovered the violation after committing to a branch and re-running — at which point it correctly failed with \"does not exactly match the audited application of 0 moved inbox request(s) from the base\". The green was real but meaningless, which is the worst kind: it actively told me a forbidden edit was fine. **Outcome:** the gate either refuses to report a verdict when the working tree is dirty for the files it governs, or evaluates the working tree as well as the committed range. **Next:** make check-ledger-write-discipline.mjs detect uncommitted changes to docs/outstanding-issues.md (and the inbox directory) and either fail with an explicit \"commit before checking\" message or include them in the audited diff. Add a self-test covering the dirty-tree case, since the existing self-test passes today. **Related contributing factor worth fixing in the same pass:** `node scripts/outstanding-issues.mjs done ...` and `npm run issues:done` are different tools — the first edits the canonical ledger in place (reconcile-side), the second queues a merge-safe inbox request via scripts/ledger-inbox.mjs (branch-side). Nothing at the call site says so, and the raw script is what AGENTS.md's usage header documents. Consider making scripts/outstanding-issues.mjs refuse to run outside a reconcile context, or print a pointer to issues:done. **Stop:** do not \"fix\" this by relaxing the discipline check — the check itself was right, it just was not asked the right question.",
+ "source": "session 2026-08-13 closing #170/#309; scripts/check-ledger-write-discipline.mjs; scripts/ledger-inbox.mjs vs scripts/outstanding-issues.mjs"
+ }
+}

docs/outstanding-issues-inbox/4bb5ba0d-ca46-454e-97f4-5a49f5c87f22.json

@@ -0,0 +1,10 @@
+{
+ "version": 1,
+ "id": "4bb5ba0d-ca46-454e-97f4-5a49f5c87f22",
+ "createdOn": "2026-08-13",
+ "action": "update",
+ "payload": {
+ "id": "#309",
+ "detail": "Raised by the Codex reviewer on PR #1858 and correct. docs/filter-contract.md section 5 sets density by option count: <=5 chips, 6-20 dense full-width list with a right-aligned count column and group headings, >20 or >3 groups adds find-a-filter and collapse-by-default. **PARTIALLY DELIVERED 2026-08-13, and the part this row was opened for is NOT done.** PR F (#1910) ported documents' implementation up into the shared ResultFilterSheet, so the >20-or->3-groups tier now exists there: find-a-filter, per-group collapse-by-default, a group opening itself when it holds a selection, and a live needle owning openness. That is the tier documents needed. **The 6-20 band is still unimplemented.** result-filter-control.tsx computes `const dense = facetGroups.length > 3 || totalFacetOptions > 20`, so a mode with one facet group of nine options — formulation, the exact case that opened this row — evaluates dense=false and still renders ResultFilterFacetChips as a wrapping chip row. Verified 2026-08-13 on main 2d27039: formulation passes one group with formulationDomainsInUse.length === 9, so neither condition fires. An earlier attempt to close this row as delivered was wrong and was caught in review on PR #1925; the mistake was conflating \"the dense tier landed\" with \"this row's band landed\" — section 5 has two thresholds and only the upper one shipped. **Next:** either implement the 6-20 full-width renderer with the right-aligned count column and add the nine-option DOM assertion this row already asked for, or amend section 5 to drop the middle band deliberately and record that the contract was reversed rather than satisfied. **Stop:** do not close this row on the strength of the >20 tier, and do not add a per-mode dense list — a second hand-rolled facet layout is the drift the shared renderer was extracted to remove."
+ }
+}

docs/outstanding-issues-inbox/e48b440b-d5a0-436b-bea8-ca7670d1a6bb.json

@@ -0,0 +1,10 @@
+{
+ "version": 1,
+ "id": "e48b440b-d5a0-436b-bea8-ca7670d1a6bb",
+ "createdOn": "2026-08-13",
+ "action": "done",
+ "payload": {
+ "id": "#170",
+ "outcome": "DELIVERED and verified by content on main 2d27039 (2026-08-13), not by PR state. Every mode named in this row now uses the shared ResultFilterTrigger + ResultFilterSheet under the lens/facet contract in docs/filter-contract.md. Services: src/lib/service-facets.ts exists, the navigator imports resultFilterFacetGroup, the scope segment is a SegmentedControl backed by a `scope` URL param, and the six query-replacing quick filters now feed AnswerSuggestionChips as composer suggestions instead of the sheet (PR C). Factsheets: converted to SegmentedControl with per-option counts; no eviction was needed because the earlier plan's claim that its presets discarded the query was measured false — searchHref keeps `q` and adds `category` (PR D). Therapy-compass: src/components/therapy-compass/filter-sheet.tsx DELETED, screens/search-screen.tsx converged onto the shared control (PRs #1885, #1889). Documents: converged onto the shared sheet with meterContent and footerOverride so its progress meter and Browse all sources footer survive (PR #1910). The contract also spread past the original six — dsm-search-page, forms-search-results-page, tools-search-results-page and differential-stream-workspace are on the shared sheet. Foundations: #1847 kinds + contract doc, #1848 SegmentedControl hint slot, #1857 four lens modes, #1858 formulation first facet adoption. REMAINING and tracked elsewhere, not part of this row: #275 (shared trigger's arbitrary spacing across five files) and filter-contract.md section 7 (SearchScopeFilters, 20 server-side keys editable from no panel, explicitly not a prerequisite)."
+ }
+}