case-project-upgrade

name

case-project-upgrade

description

Safely upgrade or migrate an existing elder-care case workspace created with an older plugin layout into the current privacy-first structure without losing source material. Use when the user says "upgrade my case project", "migrate old case folder", "move this case to the new layout", "prepare my existing case folder for this plugin", "don't lose existing findings", or needs a dry-run migration plan, checksums, backup manifest, case-context creation, and no-delete/no-overwrite transfer workflow before publishing or updating the plugin.

Case Project Upgrade

Safely migrate an existing private case workspace into the current elder-care-casework layout. This skill exists because long-running SNF / Medicare / Medicaid cases accumulate high-value artifacts over months: raw HIPAA productions, OCR text, findings, appeal drafts, admin logs, JFS letters, complaint drafts, and attorney-intake packets. Upgrades must preserve everything.

The default posture is dry-run, no delete, no overwrite. Source files remain where they are until the user explicitly approves a copy plan.

When to invoke

• The user has an older case workspace and wants to keep using it with this plugin going forward.
• The user is preparing to publish the plugin but wants to separate reusable skills from private case files.
• The user says "migrate," "upgrade," "move to the new layout," "don't lose findings," "bring my existing project forward," or similar.
• A case has generated findings before case-context-ledger existed and those facts need to be preserved in the new evidence register.

Target private-case layout

Use this layout inside the user's private case workspace. Do not commit populated folders.

case-workspace/
├── case-context/             # durable memory ledger consumed by other skills
├── records/                  # raw PDFs and source productions
│   └── derived/              # OCR text, optimized PDFs, chart parts
├── inventory/                # inventory JSON and summaries
├── review-output/            # Findings / HotItems / Timeline / Gaps / JSON roll-ups
├── correspondence/           # emails, records requests, admin logs
│   └── admin-log/
├── appeals/                  # appeal supplements, critiques, payer letters
├── complaints/               # ODH / ODI / AG / CMS / Ombudsman drafts and filed copies
├── medicaid-correspondence/  # JFS / ODM letters
├── legal-referral/           # attorney / legal-plan intake packets
└── migration/                # upgrade manifests and reports

Inputs to collect

Ask only for missing information.

1. Existing case root — the older project/folder to inspect.
2. Target case root — where the upgraded private workspace should live. Default: same root, using the target layout above.
3. Copy mode — DRY-RUN first; then one of COPY, LINK, or LEAVE-IN-PLACE-AND-INDEX. Default is DRY-RUN.
4. Case prefix — short non-public label used for generated roll-ups.
5. Known stay window — optional but useful for reviewing inventories and timelines.
6. Whether the workspace is a git repo — if yes, verify private output paths are ignored before copying.
7. Privilege / sensitivity policy — whether attorney-sourced files should be indexed only, excluded from migration, or copied into a privileged/ subfolder.

Safety principles

1. Dry-run first. Never move, delete, rename, or overwrite files during discovery.
2. Hash before copying. Every source file in the upgrade manifest gets SHA-256, size, category, and proposed target.
3. Preserve originals. Default transfer mode is copy; move is not allowed by this skill.
4. No overwrites. If a target exists, mark a collision and ask the user. Do not overwrite.
5. Keep PHI local. Do not paste PHI-heavy paths or contents into chat. Summarize counts/categories.
6. Respect privilege. Attorney-sourced or strategy files should be marked before they flow into complaints or legal-referral packets.
7. Git hygiene before copy. If the target is inside a git repo, run ignore checks for case-context/, records/, review-output/, correspondence/, appeals/, complaints/, medicaid-correspondence/, legal-referral/, and migration/.

Execution

Phase 1 — Dry-run inventory

Run the planner script:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/case-project-upgrade/scripts/plan_upgrade.py \
  --case-root "<existing-case-root>" \
  --out-dir "<target-case-root>/migration" \
  --target-root "<target-case-root>"

It writes:

• upgrade_manifest.json — machine-readable list of files, hashes, categories, proposed targets, and collision flags.
• upgrade_plan.md — human-readable summary and next-step checklist.

The planner may regenerate those two report files on repeated dry-runs. The no-overwrite rule applies to case source artifacts and proposed migration targets, not to the planner's own report files in migration/.

Phase 2 — Human review checkpoint

Show the user a short non-PHI summary:

• total files and bytes scanned
• counts by category
• target collisions
• unclassified files needing user review
• whether git ignore checks passed

Do not copy anything until the user approves the plan.

Phase 3 — Copy / link / index

After approval, implement only the approved mode:

• COPY — copy files into the target layout while preserving timestamps and originals.
• LINK — create local symlinks when the user wants one canonical raw-record store.
• LEAVE-IN-PLACE-AND-INDEX — do not copy source artifacts; create/update document_index.md entries pointing to existing locations.

For COPY, prefer a tool or command that preserves timestamps and refuses overwrites (rsync --archive --ignore-existing or equivalent). After copying, recompute hashes for copied files and compare to the manifest.

Phase 4 — Create/update case context

Run or invoke case-context-ledger to create/update:

• case_profile.md
• deadlines.md
• document_index.md
• evidence_register.md
• issue_log.md
• open_questions.md
• decision_log.md

Populate only source-backed facts. For prior *_HotItems.md, *_Findings.md, or *_Findings.json, add value-3 findings to evidence_register.md with confidence markers (verified, OCR-partial, needs visual check) rather than re-reading the whole chart during migration.

Phase 5 — Upgrade report

Write <target-case-root>/migration/upgrade_report.md using references/upgrade_report_template.md.

The report must include:

• what was scanned
• what was copied / linked / indexed
• collisions skipped
• unclassified files needing review
• hash verification results
• case-context files created/updated
• next recommended skill to run

Chat summary conventions

Report only operational metadata in chat:

• files scanned / copied / linked / indexed
• categories and collision counts
• target paths for reports
• user decisions still needed

Do not paste patient names, DOBs, case numbers, chart quotes, or attorney strategy into chat unless explicitly requested.

Guardrails

• This is migration support, not medical or legal advice.
• Do not delete, move, rename, or overwrite source artifacts.
• Repeated dry-runs may overwrite migration/upgrade_manifest.json and migration/upgrade_plan.md; copy or rename those reports first if the user needs to preserve an earlier run.
• Do not include privileged files in public or regulatory outputs unless the user/counsel explicitly approves.
• If existing records are not OCR'd or are corrupted/encrypted, record that in the upgrade report and route to snf-inventory remediation; do not treat migration as review.
• If a prior generated finding lacks a source citation, keep it in the document index but do not promote it into the evidence register as canonical.