Daily rituals stop doing the same work twice (release v1.97.19)

[davekilleen]

Linked Issue

• Linear issue: none (user report from Michelle: daily-plan and daily-review taking about 40 minutes a day, roughly 15 of it gathering before the first question)

What Changed

• One meeting pass per ritual. daily-review Step 1.5 no longer runs /process-meetings today in the conversation; the helper's Step 0 catch-up (every unprocessed meeting since the last processed one) is the evening's only pass. daily-plan Step 0 first asks node .claude/hooks/meeting-queue-check.cjs --count and only runs the seven-day pass when the count is above zero (no output or failure is treated as unknown, not zero).
• meeting-queue-check.cjs --count. New count-only mode: bypasses the 30-minute notice throttle, never writes the throttle marker, prints one integer.
• Gathering helpers run on the fast tier. The Agent call in daily-plan, daily-review and process-meetings passes model: "sonnet". The frontmatter's model_routing.steps.data-gathering: fast was declared but nothing wired it.
• Batching preambles in the three AGENT_INSTRUCTIONS.md briefs: independent reads go out in one turn, then per-meeting enrichment, then writes. Every existing step, gate and post-condition is unchanged.
• Narrow verify pass. The process-meetings helper's report ends with a Touched block (task IDs, stamped notes, created pages); the conversation verifies exactly those instead of re-reading Tasks.md and every note.
• doctor.py --only CHECK_ID (repeatable). daily-plan's email step runs --deep --only mail.apple-search instead of the whole live registry; Google Workspace needs no local probe. A narrowed run never replaces the health snapshot; an unknown id is an error.
• Portable adapters (.agents/skills) and the plugin package regenerated; core/harnesses/portability.json gives daily-plan a host-neutral replacement for the hook command; Lens registry pins refreshed for the three skills.
• Main merged in (it moved to v1.97.18 while this was open); the only conflict was the Lens registry pins, re-pinned against the merged skill files.
• Release bump to v1.97.19 via scripts/release.sh patch with the CHANGELOG entry in house style. The tag is created on the merge commit after this lands.

Test Plan

• Unit/integration tests added or updated: four hook tests for --count (throttle bypass, no marker write, zero case, CLI output); three doctor tests for --only (narrowing, order, snapshot not published, unknown id rejected); one instruction-contract test pinning the single-probe wording in daily-plan.
• Negative/error-path tests added or updated: --only with an out-of-registry or unknown id returns exit 1 with no JSON; --count returns 0, not a notice, when nothing is waiting.
• Commands run locally on the merged tree: npm run test:hooks (278 pass), npm run test:scripts (194 pass with DEX_PYTHON set), the 18 instruction-contract / doctor / Lens / portable-contract suites (773 pass), python3 scripts/check-instructed-tools.py, generate-agents-skills.py --check, generate-portable-plugin.py --check, ruff check core/, portable-contract / architecture-inventory / path-consistency / founder-content / PII / security gates. Full pytest before the merge: 5372 pass; 18 failures all environmental in this sandbox (root reads "unreadable" files, shallow history, process-group timeouts) and reproduced identically on the untouched tree.

Ralph Wiggum Loop

• I implemented the change.
• I self-reviewed for defects and edge cases.
• I requested specialist review for risky areas (testing/infra/security when relevant).
• I addressed review findings and re-ran checks.

Quality Gates

• I added/updated tests or documented why no tests are needed.
• I added a regression test for bug fixes, or this PR is not a bug fix.
• I validated failure modes / edge cases.
• I updated docs or confirmed no docs impact.
• CI checks for lint + tests + coverage are expected to pass.

Risk & Rollback

• Risk level (low/medium/high): low. Skill-brief wording plus two small, tested code paths (--count, --only). The one behavioural change with a failure mode is daily-plan skipping the meeting pass on a zero count; the evening catch-up window still covers any note the sweep does not count, and any non-integer answer falls back to the old behaviour.
• Rollback plan: /dex-rollback to v1.97.18, or revert the release and feature commits.

Docs Impact

• Files updated: CHANGELOG.md (v1.97.19 entry), docs/UPDATE-RESCUE.md (version bump by the release script).
• If none, reason: n/a

🤖 Generated with Claude Code

https://claude.ai/code/session_0113icGZrCbSBmwomv7e49bH

[cursor]

Approved. Cursor Bugbot was not present after the first check poll, so that signal was skipped. No approval policy required human review, and reviewers were not assigned.

  

_{Sent by Cursor Approval Agent: Pull Request Router and Approver}

[github-actions]

What this pull request touches

• skills — feeds the guided workflows and commands people use with Dex.
• session hooks — feeds starting sessions and carrying useful context into the next interaction.
• build & release — feeds turning a reviewed contribution into a safe Dex update.
• the trust engine — feeds safe diagnostics and health checks for installed and customized Dex setups.
• tests — feeds catching regressions before contributors and users encounter them.

Gates that will judge this change

• Personal-data gate: added lines must not expose real identities or personal vault content.
• Change-aware gates: source changes are checked for tests, path-contract use, documentation drift, and touched-file coverage.
• Tests and coverage: the Python, MCP, migration, hook, and script suites must remain healthy.
• Safety and quality: security, lint, distribution, path consistency, and large-vault checks still apply.

Based on 35 changed files.

[davekilleen]

CI status on this PR, for the record:

• tests (1) → test_harness_portability::test_portability_manifest_is_current: mine, fixed in 972f5dc. The daily-plan replacement rule had been written into core/harnesses/portability.json by hand; it now lives in scripts/generate-harness-portability.py and the regenerated manifest is byte-identical to the committed one.
• tests (1) → test_update_checker::test_fetch_rejects_tag_object_that_differs_from_remote_enumeration (evidence-invalid instead of tag-object-mismatch): not code this PR touches (core/utils/update_verifier.py and that test are unchanged since 2026-08-13). It passes locally three times in a row, and main's last CI run failed only on the tag-gated build-release job, so main's tests are green. The evidence-invalid code is what the verifier returns when the session deadline is exceeded, which points at runner timing on the macOS shard. Watching whether it recurs on the new head; if it does, the deadline in that test is the thing to look at, not this diff.
• review (the optional Claude review workflow): fails inside claude-code-action after one turn with zero model usage (is_error: true, modelUsage: {}), i.e. before it reads the PR. That is the action's own auth or config, not this diff, and it failed the same way on the previous head. It is not a required check; nothing to port.

---

Generated by Claude Code

[davekilleen]

historic-fleet-darwin-pr-canary is red on this head, and it is not this PR's. It is also the reason I am holding the v1.97.19 tag.

What fails: FAIL: v1.51.0: release contains a path the ownership contract refuses: System/knowledge-half-life.example.yaml [unclassified-never-write].

Why: #744 (e37b4b8d, knowledge half-life) added two shipped seed files, System/knowledge-half-life.yaml and System/knowledge-half-life.example.yaml, and added their rules to core/portable_contract.py. But build_update_plan runs the installed vault's contract, not the release's, and every contract before #744 returns unclassified-never-write for both paths. I reproduced it with the v1.97.18 contract (8cf7dd84):

System/knowledge-half-life.example.yaml -> unclassified-never-write
System/knowledge-half-life.yaml         -> unclassified-never-write
System/pillars.example.yaml             -> write-if-absent seed   (control)

So this is not only the historic v1.51.0 journey: any release built from current main would be refused by every existing vault's /dex-update with that same message. The canary passed on this PR's previous head (972f5dc9, before main's #744 was merged in) and only runs on pull requests, so main itself shows no red for it.

No fix exists on main yet. Two candidate fixes, both outside this PR's scope:

1. Two-release protocol: ship the contract rules now, and the two seed files in the release after that, once installed contracts know them. Cheapest: add both paths to .distignore for this release (the feature is not wired into any skill yet, and a missing config already reads as UNAVAILABLE by design).
2. Make the updater forward-compatible: let build_update_plan consult the release's shipped contract (packages/dex-contracts/dist/portable-vault.contract.json) for paths the installed contract does not classify, restricted to seed (write-if-absent) so it can never widen a write.

Until one lands, merging this PR is safe (main already carries the regression), but tagging v1.97.19 is not.

---

Generated by Claude Code