Follow-up fixes from the SPEC-47/SPEC-82 stack

[phernandez]

Goal

Close the defects found while landing #1416, #1421, #1423, #1424, #1426 and #1429, then re-measure the benchmarks on the surface that actually shipped.

Issues

	area	why it matters
#1414	project add / readiness	Blocks the benchmark re-run. project add registers without indexing and status reports ready vacuously, so an eval runs against an empty project and returns a plausible zero instead of an error. Already invalidated one A/B run as 0/12.
#1432	MCP routing	read_note and search resolve an unqualified name into another accessible workspace. The POSIX verbs were fixed in #1421; these two kept the bare-prefix fallback because they have no mount table to refuse against.
#1435	MCP paths	find --meta returns search results that skip the re-qualification ls/find/cat now do, so its results don't round-trip.
#1431	search	Vector/hybrid filter intersection caps the filter scan at 50,000 rows and treats everything beyond as disallowed. Deterministically biased against newer content on Postgres.
#1437	search index	A relation permalink can collide with an observation's. Postgres raises IntegrityError; SQLite silently keeps both under one permalink. Pre-existing on main.
#1430	CI / SQLite on Windows	Three symptoms — a hang, a database is locked, and a 45-minute job timeout — all consistent with SQLite operations serializing on Windows. Makes CI unreliable for every PR.

Approach

Independent PRs off main, not a stack. The stack that produced these issues cost three separate cascade repairs: a rebase of a lower branch orphans everything above it, and GitHub's stacked-merge auto-rebases the child on every merge, doing the same thing again. These six touch largely separate areas, so only the second-merged in an overlapping pair pays a rebase.

Grouping by area rather than one PR each, so a shared rule gets stated once:

• project add should index by default and expose a trustworthy readiness signal #1414 alone — unblocks the benchmark work and touches CLI/readiness only.
• read_note and search resolve unqualified names into other accessible workspaces #1432 + find --meta results do not round-trip: search-result paths skip re-qualification #1435 — both are "an identifier or path is resolved or returned wrongly" in the MCP layer.
• Vector/hybrid filter intersection drops candidates beyond VECTOR_FILTER_SCAN_LIMIT #1431 + search_index permalink collision between observation and relation rows #1437 — both are search-index correctness; search_index permalink collision between observation and relation rows #1437 needs a migration.
• Windows CI: test_chatgpt_search_pagination_default hangs in an aiosqlite call #1430 — diagnosis first; the fix may be configuration rather than code.

Then

Re-measure the agent-task A/B on the merged surface. The headline 12/12 at −36% tokens was recorded on an earlier build, before the routing rework, the MetadataPath funnel, and field-projection validation. Carrying that number forward would be reporting a result for code that no longer exists.

Also outstanding on #1398: curated-ingestion BEAM mode (only the raw baseline exists), the xAFS audit, and the Moby Dick qualitative run.

[claude]

Claude finished @phernandez's task in 53s —— View job

---

Triage

Type: Bug (tracking issue for defects found while landing the SPEC-47/SPEC-82 stack; also scopes a benchmark re-run once the fixes land)
Priority: High — #1414 blocks the benchmark re-run entirely (silent false-ready state already invalidated an A/B run), and #1430 makes CI unreliable for every PR. The remaining items (#1432, #1435, #1431, #1437) are Medium: real correctness bugs with a clear repro but narrower blast radius.
Component: Spans CLI/readiness (#1414), MCP tools/routing (#1432, #1435), search/search-index (#1431, #1437), and CI (#1430) — no single repo component label fits an umbrella issue like this.
Complexity: Medium overall. Individually most sub-issues look like small, well-scoped fixes; #1437 needs a migration and #1430 requires diagnosis before a fix is known. Complexity is in sequencing six independent PRs cleanly off main, not in any single fix.

Verified all six linked issues (#1414, #1431, #1432, #1435, #1437, #1430) exist and are open, so the dependency list is accurate. No duplicate tracking issue found via search.

This is a well-formed umbrella/planning issue with a clear approach already laid out; no clarification needed. Per triage scope, no implementation, labels beyond triage-owned, or branch/commit work was done here.

[phernandez]

Cloud must stamp last_indexed_at before re-pinning

#1440 (for #1414) adds project.last_indexed_at as the one durable signal separating "never indexed" from "indexed and idle". Every other signal is a count, and a count of zero is ambiguous exactly where it matters — that ambiguity is what made status report ready vacuously.

The marker is stamped by run_local_project_index. The cloud runtime goes through ProjectIndexWorkflowStarter and never reaches that call, so cloud projects would report never_indexed forever.

Nothing breaks: the ProjectIndexObserver protocol is deliberately unchanged and readiness is a separate service, so this is a wrong readout rather than a failure. But it makes the new contract useless in cloud, and a hosted caller waiting on readiness would wait forever.

Action: the cloud runtime needs to stamp the marker on a completed index pass before the next core re-pin. Worth checking at the same time whether the phase reporting needs anything else cloud-side, since indexing and failed were left out of the local model specifically because they are unobservable in-process — cloud runs the pass in a worker and may be able to observe both, in which case the enum grows rather than the readout being approximated.

[phernandez]

#1440 merged as a92b1ac (closes #1414). Final round widened two guards from the site where each bug was found to the property: every constructed command in src/ is now swept for mode-restricted remedies (tests/test_remedy_emission_sites.py), and the vector-sync deferral recorder runs on the raising path as well as the returning one.

Still open from this tracker on the cloud side: the cloud runtime must stamp project.last_indexed_at before the next core re-pin, or hosted projects report never_indexed indefinitely.

Confirmation A/B for #1398 is running now against a92b1ac.

🤖 Generated with Claude Code

https://claude.ai/code/session_014pmKq6bqCi6Zp6BTHuZjrp

[phernandez]

Two more landed today, both surfaced by the #1398 confirmation run:

• fix(core): merge the alembic heads left by #1440 and #1444 #1447 — main had two Alembic heads (fix(cli): index on project add and make status readiness honest #1440's x7d8e9f0a1b2 and fix(core): key search_index uniqueness on the row kind #1444's w6k7i8n9d0a1, both off v5o6b7s8d9e0), so every fresh database failed to initialize. Merge revision y8f9a0b1c2d3 plus tests/test_migration_graph.py, which asserts one head and fails on the pre-fix main. Linked on alembic downgrade base is broken on Postgres at head v5o6b7s8d9e0 #1445, since the suite still never runs upgrade head end to end.
• fix(core): seed agent-task projects with one index pass, and verify recency #1448 — the eval harness seeded projects with two index passes after aging mtimes (project add now indexes, and indexing rewrites notes), so every note read as recent. Now one pass, with verify_seeded_index and verify_seeded_recency reading the result back before any task runs.

Confirmation result is on #1398: posix 12/12 @ 56.5k vs rich 9/12 @ 126.8k.

🤖 Generated with Claude Code

https://claude.ai/code/session_014pmKq6bqCi6Zp6BTHuZjrp