archive(caring-contacts): preserve the design-phase iteration and its… - #2142
archive(caring-contacts): preserve the design-phase iteration and its…#2142BigSimmo wants to merge 1 commit into
Conversation
… planning trail Snapshot of the earlier Caring Contact design phase, committed so it survives outside a local worktree. This branch is an archive, not a merge candidate: its base is 279 commits behind main, and the linked prototype that superseded it merged as #2095. Kept here because it existed nowhere else: - docs/superpowers/plans/2026-08-14-caring-contact-coordination-rollout.md (1,054 lines) - docs/superpowers/plans/2026-08-15-caring-contact-design-phase.md (311 lines) - docs/superpowers/specs/2026-08-15-caring-contact-coordination-design.md (185 lines) - Eleven design-phase screen modules (today, schedule, patient agreement, patient overview, pathway selection, patient boundary, delivery exception, template, team/guidance/reporting, continuity-thread specimen, mockup primitives) that the merged prototype reorganised into product-pages/routable-suite/activation-workflow. The three planning documents are proposed for main separately; the screen modules stay here, since committing superseded modules to main would add unreachable code the repository's own dead-code gates reject. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:29 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (44)
Comment |
BigSimmo
commented
Aug 18, 2026
Checked on extracting the 3 planning documents this PR's body proposes landing separately — turns out there's nothing to extract: Since the remaining content — the 11 superseded screen modules — is explicitly described in this PR's own body as intentionally not for Generated by Claude Code |
Pull request was closed
… planning trail
Snapshot of the earlier Caring Contact design phase, committed so it survives outside a local worktree. This branch is an archive, not a merge candidate: its base is 279 commits behind main, and the linked prototype that superseded it merged as #2095.
Kept here because it existed nowhere else:
The three planning documents are proposed for main separately; the screen modules stay here, since committing superseded modules to main would add unreachable code the repository's own dead-code gates reject.
Summary
Verification
npm run verify:pr-localDuring development, use
npm run verify:cheapas the faster iteration gate before the final PR-local preflight.npm run verify:uiwhen UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changednpm run verify:releasebefore release or handoff confidence claimsFor retrieval, ranking, selection, chunking, source/citation rendering, or answer-contract changes,
verify:pr-localrunseval:rag:offlineautomatically. Run the offline command directly during iteration before spending a live eval.npm run eval:retrieval:quality(must stay 36/36) when retrieval, ranking, selection, chunking, or scoring behavior changed — CI cannot run it (needs live keys), so run it locally and paste the summary. A metadata/governance-weighting change once buried correct docs (recall 1.0→0.76) and only this eval caught it.npm run eval:rag -- --limit 15+npm run eval:quality -- --rag-onlywhen answer generation, the synthesis prompt, or answer post-processing changed (grounded-supported must not drop; citation-failure 0)npm run check:production-readinesswhen clinical workflow, privacy, environment, Supabase, source governance, or deployment behavior changednpm run check:deployment-readinesswhen deployment startup, hosting, or rollout behavior changedRisk and rollout
Complete this section for clinical, data, API, auth/privacy, workflow, dependency, build, or deployment changes.
Clinical Governance Preflight
Complete this section when the change touches ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output.
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes