feat(#12284): reminderIntensity-driven no-reply/escalation policy + quiet-watcher softening (WI-6, WI-8)

[lalalune]

What & why

Advances #12284 (parent #12186) — work items 6 + 8. Item 6's intensity lookup landed in #12952 (reminderIntensity → no-reply ladder, PA-side resolveNoReplyPolicy seam). What was still missing:

• The quiet-user-watcher signal had no structural consumer — a ≥3-day silent streak only produced morning-brief text, never a cadence change (WI-8).
• The recent-task-states log the watcher reads had no production writer — only tests seeded it, so a real quiet streak could never form.
• The intensity actually applied to a ladder was not observable in the task record.

The change

One mechanism, two signals: the quiet streak modulates behavior through the same reminderIntensity lookup #12952 added, not a second policy engine.

• no-reply-intensity.ts — new pure softenReminderIntensityForQuietStreak: a ≥3-day ignored-checkin/followup streak steps the effective intensity one notch down (persistent→normal, normal/unset→minimal; minimal and high_priority_only are fixed points). Never a guilt-framed extra poke — strictly less chasing.
• scheduler.ts — processDueScheduledTasks derives the quiet streak once per tick (via the same deriveQuietObservations helpers the watcher uses, asOf-pinned to the tick's now) and threads it into resolveNoReplyPolicy. Softening applies to reminder/checkin only; approvals keep full cadence (they gate agent-side actions; sensitive approvals fail closed). The applied intensity + softening decision are persisted on metadata.noReplyState (appliedReminderIntensity, quietStreakSoftened, quietStreakDays) so the ladder choice is auditable in the task record, not just in behavior.
• The tick now feeds the recent-task-states log for real: fires, completions, and no-reply terminal outcomes (recordTaskStateEntry, J7-guarded — a failed telemetry append never undoes a committed transition). Owner replies append the streak-breaking completed entry through both completion seams (processScheduledTaskInboundMessage and inbound-reply-completion.ts).
• recent-task-states.ts — summarize({ asOf }) pins the lookback window for deterministic tick-time evaluation; the log gets a 500-entry retention cap now that production writes exist.
• quiet-user-watcher.ts — exports quietStreakDaysFromObservations; runQuietUserWatcher accepts asOf. Brief-text behavior unchanged.

Frozen ScheduledTask contract intact: no trigger-union or schema changes — this is policy-selection lookup only, exactly as AGENTS.md:156-171 requires (structural fields, never promptInstructions text; no second scheduler).

Deviations from the issue text

• Issue mentions an escalated intensity; the ReminderIntensity enum on develop is minimal | normal | persistent | high_priority_only — there is no escalated value to handle.
• Seam choice (allowed by the WI): PA-side resolveNoReplyPolicy, not plugin-scheduling's escalation ladder — same rationale as feat(#12284): no-reply loop respects owner reminderIntensity (item 6) #12952: the spine escalation ladder drives dispatch-failure channel advance, a delivery concern owner intensity must not touch. plugin-scheduling is untouched.

Verification

• scheduler.quiet-streak.test.ts (new, real repository-backed runtime, no scheduler mocks) — 6 passed: 3 ignored check-ins driven through REAL ticks (log's production writer exercised on fire + terminal paths) soften the next reminder to fire-once with the decision visible in noReplyState; contrast persona with no history keeps the 60-min re-nudge; a reply breaks the streak (no softening); explicit persistent owner softens one notch to normal; approvals not softened; owner reply through the real MESSAGE_RECEIVED seam appends the streak-breaking log entry.
• no-reply-intensity.test.ts — 8 passed (existing 6 kept green + 2 softener unit cases).
• scheduler.no-reply-policy.test.ts — 9 passed (existing 8 kept green + new auditability case asserting appliedReminderIntensity persisted on retry). Two otherwise-identical tasks with different reminderIntensity facts → measurably different retry/ladder behavior (pre-existing feat(#12284): no-reply loop respects owner reminderIntensity (item 6) #12952 cases, still green).
• inbound-reply-completion.integration.test.ts — 5 passed; recent-task-states.integration.test.ts — 2 passed; default-pack spine-seeding + smoke — 9 passed.
• bun run --cwd plugins/plugin-scheduling test — 238 passed (19 files), untouched package stays green.
• bun run --cwd plugins/plugin-personal-assistant typecheck — exit 0; package lint:check — 0 errors (17 pre-existing warnings).
• Full PA suite (bun run --cwd plugins/plugin-personal-assistant test): 1144 passed | 9 failed | 7 skipped (1160). All 9 failures are pre-existing on clean origin/develop (b24dec8) in 4 files this PR does not touch — reproduced verbatim on a detached clean checkout (same 9 tests, same 4 files): life-reminder-datetime.test.ts (1 — the test(#12283): A2 rage-quit delete-trap regression (pending) — surfaces a destructive-action safety gap #12998 rage-quit delete-trap known-gap regression), reminders-service.process-scheduled-work.test.ts (5 — travel_reconcile subsystem from feat(#12284 item 3): real travelActive owner-fact drives the during_travel gate #13211, cache.getCache is not a function against that test's mock runtime), signature-deadline-scheduler.test.ts (1), BlockerSettingsCards.test.tsx (2). Every scheduled-task/no-reply/quiet-streak/recent-task-states suite is green.

Full verify gate (rebased on develop @ 76c9253)

bun run verify component-by-component: check:agents-claude PASS · audit:type-safety-ratchet PASS · audit:error-policy-ratchet PASS ("no new fallback-slop in touched files") · turbo typecheck lint --continue: 571/578 tasks green — the 7 failures (app#typecheck, electrobun#typecheck = the known-red baseline, plus electrobun#lint, plugin-capacitor-bridge#typecheck, plugin-computeruse#lint, plugin-sub-agent-claude-code#typecheck, tui#lint) reproduce as the byte-identical failure set on a clean detached checkout of origin/develop @ 76c9253 (this branch touches only plugins/plugin-personal-assistant + one evidence file; every failing package is byte-identical to develop here) · audit:build-model PASS · audit:turbo-build-deps FAIL — pre-existing, reproduced identically on clean develop (phantom turbo.json #build overrides for example packages left by the recent script-normalization merges; turbo.json and those packages are untouched by this branch) · audit:tee-secret-leak PASS · audit:scripts PASS · audit:test-realness PASS (report-only) · typecheck:dist PASS (28 configs).

So: verify green except pre-existing develop failures app#typecheck/electrobun#typecheck (untouched by this PR), plus the five newer pre-existing develop-drift failures and the pre-existing audit:turbo-build-deps break listed above, each reproduced on clean develop.

Evidence	Status
Real-LLM trajectory	N/A — scheduler-tick policy-selection logic, not model/prompt/action behavior (same as #12952). Domain artifacts are the evidence.
Domain artifacts	ScheduledTask noReplyPolicy/noReplyState (incl. appliedReminderIntensity, quietStreakSoftened, quietStreakDays) + recent-task-states log entries — asserted against the real repository in the integration tests above.
Backend logs	Structured [lifeops-scheduled-task] warn + runtime.reportError path on log-append failure (J7).
Frontend / screenshots	N/A — no UI surface changed.

Advances #12284. Relates to #12186.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d0d8ed5e-c060-4c3f-baa4-c6f4ce37ff7a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/12284-intensity-quiet-watcher

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[lalalune]

Independent review vs D3-intensity/quiet design: MERGE-WITH-NITS — land third, re-sync first (branch behind develop).

Closes the real D3 gap: silent-streak → gentler escalation via the #12952 intensity table, and adds the missing production writer for recent-task-states (recordTaskStateEntry on fire/complete/terminal) — previously only tests seeded it so a real streak could never form. Contract-clean, real repository-backed tick tests incl. the two-tasks-differ-only-by-intensity done-when.

Nits:

1. Double completed log entry — both MESSAGE_RECEIVED seams (processScheduledTaskInboundMessage + completeFiredTasksOnOwnerReply) call recordTaskStateEntry('completed') on one reply; harmless to streak logic but double-counts fires. Guard on already-terminal, or record from one seam.
2. One-notch softening only (no tiered-by-streak-length, no offeredPause/askScope). The tiered/pause piece overlaps the held feat(#12284 item 10): structural 'shrink the ask to one small step' ladder (replaces the promptInstructions LARP) #13221 D7 scope — leaving it out is correct; LifeOps runtime D3: structural proactive re-engagement policy and inert gate readers (#12284 split) #12779 stays partially-open on that outer edge.

Merge order: #13235 → #13233 → #13237.

[lalalune]

Reviewed (adversarial workflow): reminderIntensity-driven no-reply/escalation policy (#12284); 431-line real-runtime (no-mock) test dominates the diff. Verified against the actual diff; no failing CI. Queuing auto-merge on green.

[lalalune]

Cross-review (W1-C, #12284 WI-6+WI-8) — APPROVE

Checked out head 56f48cf (merge-base 76c9253) in an independent review lane and re-ran the claims rather than trusting them. (PR was merged by the owner mid-review; the notes below are follow-up material, none would have blocked.)

Verified

• Targeted suites reproduced green: scheduler.quiet-streak.test.ts 6 + no-reply-intensity.test.ts 8 + scheduler.no-reply-policy.test.ts 9 → 23/23 in one vitest run; inbound-reply-completion.integration.test.ts 5/5; test/recent-task-states.integration.test.ts 2/2; default-pack spine-seeding + smoke 9/9; plugin-scheduling 241/241 across 19 files (package untouched by the branch; +3 tests vs the PR body's 238 from develop drift, all green); PA typecheck exit 0.
• Pre-existing-failure claim spot-checked: reminders-service.process-scheduled-work.test.ts fails 5 with exactly the documented travel_reconcile / cache.getCache is not a function signature — and that suite vi.mocks processDueScheduledTasks entirely, so this PR's new cache read inside the real tick cannot be the cause. None of the 4 claimed-failing files appears in the 10-file diff.
• Structural-not-prompt discipline (AGENTS.md:156-171): branching is on task.kind, the owner-fact enum, and log-derived terminal streaks — no promptInstructions text branching, no persona-name branches, no second scheduler; frozen ScheduledTask contract intact (only metadata.noReplyState/noReplyPolicy bag fields + an optional provider asOf option). console.* absent from the diff.
• Done-when met: different reminderIntensity facts → measurably different retry/ladder behavior (kept-green #12952 cases + new auditability case asserting appliedReminderIntensity persisted on retry); 3-day-silent persona → next reminder structurally softened (fire-once, maxRetries: 0), asserted from the persisted policy object and driven through REAL ticks that exercise the log's new production writer on both fire and terminal paths; a reply through the real MESSAGE_RECEIVED seam appends the streak-breaking entry.
• Adversarial probes (all held): at the day-3 timeout tick the streak is still 2 (terminal trail excludes that tick's own not-yet-appended expiry), so the day-3 checkin itself is correctly unsoftened; readNoReplyState whitelists fields, so stale softening flags cannot leak into the terminal record via the ...state spread; the two MESSAGE_RECEIVED completion seams run sequentially and the second only lists still-fired tasks, so no duplicate completed append in the normal path; a cache outage inside resolveQuietStreakDays is contained by the runSubsystem("scheduled_tasks", …) guard in reminders-service.ts (subsystem-pass fallback + logged failure, loop survives) — same failure envelope as the pre-existing unguarded owner-facts read two lines above it; the log-append catch is genuinely J7-shaped (reportError, never undoes a committed transition).
• Deviation claim accurate: ReminderIntensity on develop is minimal | normal | persistent | high_priority_only (fact-store.ts:96-100) — no escalated member exists, so the issue-text escalated handling is genuinely N/A. PA-side seam is explicitly allowed by the WI ("PA-side … and/or a spine-side hook"); plugin-scheduling untouched as stated.

Notes (low severity — follow-up hardening, none merge-blocking)

1. scheduler.ts:295 — quietStreakSoftened: true persisted even when the soften is a fixed point. For an owner at minimal or high_priority_only, a quiet streak stamps quietStreakSoftened: true although the resolved ladder is identical to the unsoftened one, while the field's doc says "True when a quiet streak stepped the effective intensity down". Audit metadata over-claims for those owners. Fix: flag only when the notch actually changed the effective intensity, or re-document the field as "quiet streak active during resolution".
2. scheduler.ts:469 — degraded telemetry degrades too much. resolveQuietStreakDays is unguarded, so a cache failure aborts the whole scheduled_tasks subsystem pass for the tick (no reminders/approvals processed until cache recovers) instead of just skipping softening — while the WRITE side of the same log is deliberately J7-guarded. Contained by runSubsystem and matching the pre-existing owner-facts read's envelope, hence low; still, a try/catch → undefined + reportError would make the failure mode "no softening" rather than "no pass".
3. providers/recent-task-states.ts:147 — every log entry counts as a "fire". Now that the production writer appends both a fired and a terminal entry per lifecycle, the provider's "(over N fires)" summary text double-counts (the quiet-streak test's own 5-entry log reads as "over 5 fires" for 3 check-ins). Streak derivation is terminal-only and unaffected; this is planner/brief-facing text accuracy only. Fix: count only outcome === "fired".
4. providers/recent-task-states.ts:98-110 — read-modify-write append race. appendScheduledTaskLogEntry does getCache → push → setCache with awaits in between; a MESSAGE_RECEIVED completion append racing a tick append can drop an entry (worst case the streak-breaking completed, leaving softening active one extra evaluation). Tiny single-process window and self-healing on the next reply, but worth compare-and-append or per-runtime serialization as the log gains writers.
5. Cosmetic: the evidence file header says "based on develop @ b24dec8" — stale after the rebase to 76c9253 (the PR body is correct).

Not re-run here: the full PA suite and full bun run verify (the PR documents byte-identical reproductions of the drift set on clean develop; the touched package is 100% green above, and the failing packages/files are untouched by this diff — spot-checked one of the four failing files as described).

Verdict: approve.

[github-actions]

❌ PR title does not match the required pattern. Please use one of these formats:

• 'type: description' (e.g., 'feat: add new feature')
• 'type(scope): description' (e.g., 'chore(core): update dependencies')
  Valid types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert, release