Skip to content

docs(caring-contacts): land the rollout plan, design-phase plan and coordination spec - #2133

Merged
BigSimmo merged 3 commits into
mainfrom
claude/caring-contact-planning-docs
Aug 18, 2026
Merged

docs(caring-contacts): land the rollout plan, design-phase plan and coordination spec#2133
BigSimmo merged 3 commits into
mainfrom
claude/caring-contact-planning-docs

Conversation

@BigSimmo

Copy link
Copy Markdown
Owner

Summary

Lands the planning trail behind the Caring Contact prototype. The prototype itself merged as #2095; the reasoning that produced it was still sitting uncommitted in a local worktree with no remote branch, roughly 1,550 lines that existed nowhere else and would have gone with that directory.

  • 2026-08-14-caring-contact-coordination-rollout.md (1,054 lines) — the repository-native rollout, staged from an approved visual and clinical-operating model through a controlled synthetic-data build, governed integration, limited pilot and measured expansion. This is the document that constrains the prototype: a dedicated route group rather than a searchable Clinical KB mode, no patient data through the existing RAG/OpenAI path, and an explicitly approved PHI-capable identity, hosting, datastore, audit, records and SMS boundary required before any real-patient use.
  • 2026-08-15-caring-contact-design-phase.md (311 lines) — the design phase plan.
  • 2026-08-15-caring-contact-coordination-design.md (185 lines) — the binding synthetic-design specification, tied to the design-system SPEC / TOKENS / COMPONENTS / GATES.

Documents only. No code, no routes, no configuration.

What was deliberately not landed

The same worktree held eleven superseded design-phase screen modules — today, schedule, patient agreement, patient overview, pathway selection, patient boundary, delivery exception, template, team/guidance/reporting, a continuity-thread specimen and mockup primitives. The merged prototype reorganised those into product-pages / routable-suite / activation-workflow, so committing them here would add unreachable modules that this repository's dead-code gates reject. They are preserved on the archive branch codex/caring-contact-design-20260815 instead, which now exists on the remote for the first time.

Verification

  • npm run docs:check-linksdocs link check passed: 1901 repo path references resolve (the spec cross-links four design-system documents, so this is the check that matters).
  • npm run format — clean.

Not run, with reason: lint, typecheck, the unit suite and browser gates. The diff is three Markdown files under docs/superpowers/; none of those gates has a failure path here.

Risk and rollout

  • Risk: None to running behaviour — documentation only.
  • Rollback: revert this PR's squash commit.
  • Provider or production effects: None.

Notes

  • Worth reading rather than filing: the rollout plan is explicit that the current Clinical KB deployment is not assumed suitable for real patient use, and names the approvals required first. That constraint is now in the repository alongside the prototype it governs, instead of only in a worktree.

…oordination spec
The Caring Contact prototype merged as #2095, but the reasoning that produced it
stayed in an uncommitted local worktree with no remote branch — roughly 1,550
lines that existed nowhere else and would have vanished with that directory.
- 2026-08-14 rollout plan (1,054 lines): the repository-native rollout, staged
from approved visual and clinical-operating model through synthetic-data build,
governed integration, limited pilot and measured expansion. It records the
decisions that constrain the prototype — dedicated route group rather than a
searchable Clinical KB mode, no patient data through the RAG/OpenAI path, and an
explicitly approved PHI-capable identity, hosting, datastore, audit and SMS
boundary required before any real-patient use.
- 2026-08-15 design-phase plan (311 lines).
- 2026-08-15 coordination design spec (185 lines): the binding synthetic-design
specification, tied to the design-system SPEC/TOKENS/COMPONENTS/GATES.
Documents only. The eleven superseded design-phase screen modules from the same
worktree are archived on codex/caring-contact-design-20260815 rather than landed
here, since they were reorganised into the merged prototype and would otherwise
add unreachable modules that the dead-code gates reject.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@coderabbitai

coderabbitaiBot commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:1 minute

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8e8fcf64-f650-4020-b867-3273208d7b2c

📥 Commits

Reviewing files that changed from the base of the PR and between f55e440 and dc8955a.

📒 Files selected for processing (3)
  • docs/superpowers/plans/2026-08-14-caring-contact-coordination-rollout.md
  • docs/superpowers/plans/2026-08-15-caring-contact-design-phase.md
  • docs/superpowers/specs/2026-08-15-caring-contact-coordination-design.md

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

@supabase

supabaseBot commented Aug 18, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

@BigSimmo
BigSimmo marked this pull request as ready for review August 18, 2026 16:16
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

@BigSimmo
BigSimmo enabled auto-merge (squash) August 18, 2026 16:20
@BigSimmo
BigSimmo merged commit f55edd1 into mainAug 18, 2026
23 checks passed
@BigSimmo
BigSimmo deleted the claude/caring-contact-planning-docs branch August 18, 2026 16:21
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@BigSimmo