cc-session-tools 3.3.0__tar.gz → 3.3.1__tar.gz

{cc_session_tools-3.3.0/src/cc_session_tools.egg-info → cc_session_tools-3.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.0
+Version: 3.3.1
 Summary: Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)
 Author: raffishquartan
 License: MIT License

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "cc-session-tools"
-version = "3.3.0"
+version = "3.3.1"
 description = "Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)"
 readme = "README.md"
 license = { file = "LICENSE" }

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools/lib/pdata/resolve.py

@@ -8,7 +8,7 @@ overwrite (that is rehydrate.py's job for the clean fast-forward case; this modu
 
 Never auto-merges, never silently keeps one side and discards the other — every record surfaced
 here needs an explicit choice from the caller (ultimately Chris, via the CLI/skill), matching the
-existing `pm-pdata-conflict-resolution` skill's single-file-conflict framing exactly. Every
+existing `pm-pdata-resolve-conflicts` skill's single-file-conflict framing exactly. Every
 record: `apply_resolution` is all-or-nothing over the whole diff, for the reasons in its own
 docstring.
 
@@ -342,7 +342,7 @@ def _apply_resolution(
             f"record_id(s) {collisions}: id collision (the same id was independently assigned to "
             f"two unrelated records) — not resolvable as a local/dump choice, since either pick "
             f"would discard one side's real record; needs a manual, out-of-band fix (see the "
-            f"pm-pdata-conflict-resolution skill, point 4)"
+            f"pm-pdata-resolve-conflicts skill, point 4)"
         )
 
     group_mismatches = sorted(rid for rid, rd in by_id.items() if rd.group_mismatch)
@@ -351,7 +351,7 @@ def _apply_resolution(
             f"record_id(s) {group_mismatches}: group mismatch (same id and created_at, but the "
             f"two sides disagree on record_group) — not resolvable as a local/dump choice. "
             f"Compare each side's content/file_path before assuming a rename is safe (see the "
-            f"pm-pdata-conflict-resolution skill, point 5, for why it may instead be a "
+            f"pm-pdata-resolve-conflicts skill, point 5, for why it may instead be a "
             f"same-second id collision), then retry"
         )
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools/lib/pdata/service.py

@@ -310,7 +310,7 @@ def update_record(
     content and fields are independent — updating fields never re-serializes content, and vice
     versa. This is deliberate (it's what lets a --field-only update skip resending content), not
     a gap: a record group whose content is designed to mirror its fields is the caller's own
-    duplication to keep in sync, on every write, by passing both. See pm-pdata-schema-design
+    duplication to keep in sync, on every write, by passing both. See pm-pdata-design-schema
     SKILL.md's "content and extension fields are never auto-synced" section."""
     if content is None and file_path is None and not fields:
         raise ValueError(

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-schema-design → cc_session_tools-3.3.1/src/cc_session_tools/skills/pm-pdata-design-schema}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pm-pdata-schema-design
+name: pm-pdata-design-schema
 description: Use before writing a genuinely new kind of structured data into any project's ccst pdata store - deciding whether it fits an existing record_group, needs a brand-new group, and whether that group needs an extension table or free-text content suffices. Triggers on "I need to track a new kind of record", "what record_group should this be", "does this need an extension table", "add a new field to ccst pdata", or any session about to call `ccst pdata add`/`schema add-field` for a record shape it hasn't used before. Prevents lazy catch-all groups (`notes`/`misc`) that silently recreate the EAV undifferentiated-bucket problem the schema deliberately rejected.
 ---
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools/skills/pm-pdata-do-audit-and-prepare-to-migrate/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: pm-pdata-do-audit-and-prepare-to-migrate
-description: Full consistency/completeness audit of a project's central and recordkeeping files - OneDrive sync-conflict cleanup, cross-checking every index/register/log against what it claims to describe, and a pdata-migration readiness pass. Ends by writing a readiness manifest file that feeds `ccst pdata init` (via `pm-project-init`) - the tool-native migration mechanism - and, only for the narrow record shapes it can't express, the deprecated `pm-pdata-do-migrate` fallback. Triggers on "review all my central files", "audit the project files", "check everything is up to date and consistent", "get this project ready for pdata", "/pm-pdata-do-audit-and-prepare-to-migrate", or any request for a thorough review/health-check of a project's index/log/register files (as opposed to a single-session wrap-up, which is pm-update-central-files). Especially relevant when a project is scheduled to migrate to pdata - this audit is the recommended prerequisite pass, since a schema design should not be built against files that still have unresolved sync-conflict duplicates or known dangling rows.
+description: Full consistency/completeness audit of a project's central and recordkeeping files - OneDrive sync-conflict cleanup, cross-checking every index/register/log against what it claims to describe, and a pdata-migration readiness pass. Ends by writing a readiness manifest file that feeds `ccst pdata init` (via `pm-project-init`) - the tool-native migration mechanism - and, only for the narrow record shapes it can't express, the deprecated `pm-pdata-do-manual-migration` fallback. Triggers on "review all my central files", "audit the project files", "check everything is up to date and consistent", "get this project ready for pdata", "/pm-pdata-do-audit-and-prepare-to-migrate", or any request for a thorough review/health-check of a project's index/log/register files (as opposed to a single-session wrap-up, which is pm-update-central-files). Especially relevant when a project is scheduled to migrate to pdata - this audit is the recommended prerequisite pass, since a schema design should not be built against files that still have unresolved sync-conflict duplicates or known dangling rows.
 ---
 
 # Audit central files
 
 > **This audit feeds `ccst pdata init`, not a manual migration.** The readiness manifest this
 > skill produces (Phase 5) is a pre-flight pass for `ccst pdata init` (driven by the
-> `pm-project-init` skill) - the tool-native, default migration mechanism. `pm-pdata-do-migrate`
+> `pm-project-init` skill) - the tool-native, default migration mechanism. `pm-pdata-do-manual-migration`
 > is a deprecated fallback for record shapes `ccst pdata init` genuinely can't express; it is not
 > the default next step after this audit.
 
@@ -121,7 +121,7 @@ Give the user a single reviewable delete script for every confirmed-safe deletio
 ## Phase 4: pdata-readiness pass
 
 Compile a dedicated `pdata-readiness-notes.md` (or equivalent) listing, file by file, every
-blocker a future `pm-pdata-schema-design` session would hit if it tried to design a schema
+blocker a future `pm-pdata-design-schema` session would hit if it tried to design a schema
 against the file as it currently stands:
 
 - Inconsistent separator/delimiter use within one logical column.
@@ -137,7 +137,7 @@ against the file as it currently stands:
   means something different from a genuinely blank one).
 
 This file is deliberately NOT a migration plan - it's a findings list for whoever runs the actual
-`pm-pdata-schema-design` session next, so that work isn't designed against a still-messy
+`pm-pdata-design-schema` session next, so that work isn't designed against a still-messy
 substrate.
 
 ## Phase 5: write the readiness manifest (for `ccst pdata init`/`pm-project-init` to consume)
@@ -152,7 +152,7 @@ recorded in the project's own instructions file (`CLAUDE.md`/`AGENTS.md`/equival
 session doesn't have to search for it.
 
 The manifest must have, in this order, so a `pm-project-init` session running `ccst pdata init`
-(or, for the narrow record shapes it can't express, the deprecated `pm-pdata-do-migrate`
+(or, for the narrow record shapes it can't express, the deprecated `pm-pdata-do-manual-migration`
 fallback) can parse it deterministically:
 
 1. **Header**: audit date, session/agent identifier, and an explicit "STALE IF" note - state the
@@ -161,7 +161,7 @@ fallback) can parse it deterministically:
 2. **File inventory**: every central/index/recordkeeping file the audit covered, with: full path,
    row/entry count, last-verified-clean date, and its role (`index`, `register`, `log`,
    `narrative`, `derived-artefact`).
-3. **Per-file migration blockers**, in the exact shape `pm-pdata-schema-design` and
+3. **Per-file migration blockers**, in the exact shape `pm-pdata-design-schema` and
    `pm-project-init` expect to consume - this is the same content this skill's own Phase 4
    already produces, just formalised into the manifest rather than a standalone prose report:
    inconsistent separators, unstable/non-existent natural keys, mixed date formats, multi-schema

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-do-migrate → cc_session_tools-3.3.1/src/cc_session_tools/skills/pm-pdata-do-manual-migration}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: pm-pdata-do-migrate
-description: Execute a project's actual migration from flat central/index files to a ccst pdata record store - build a migration plan, adversarially verify the plan itself, present it for the user's confirmation, then execute it and write a results file. Consumes the readiness manifest pm-pdata-do-audit-and-prepare-to-migrate produces if one exists, but always explores the project independently too, so it works even without that manifest. Triggers on "migrate this project to pdata", "run the pdata migration", "/pm-pdata-do-migrate", or any request to actually move a project's CSV/index/log files into pdata (as opposed to just auditing readiness, which is pm-pdata-do-audit-and-prepare-to-migrate, or designing the target schema in the abstract, which is pm-pdata-schema-design).
+name: pm-pdata-do-manual-migration
+description: Execute a project's actual migration from flat central/index files to a ccst pdata record store - build a migration plan, adversarially verify the plan itself, present it for the user's confirmation, then execute it and write a results file. Consumes the readiness manifest pm-pdata-do-audit-and-prepare-to-migrate produces if one exists, but always explores the project independently too, so it works even without that manifest. Triggers on "migrate this project to pdata", "run the pdata migration", "/pm-pdata-do-manual-migration", or any request to actually move a project's CSV/index/log files into pdata (as opposed to just auditing readiness, which is pm-pdata-do-audit-and-prepare-to-migrate, or designing the target schema in the abstract, which is pm-pdata-design-schema).
 ---
 
-# Migrate a project to pdata
+# Manually migrate a project to pdata (deprecated fallback)
 
 > **Deprecated fallback — `ccst pdata init` is the standard mechanism.** `ccst pdata init`
 > (driven by the `pm-project-init` skill) is the tool-native migration mechanism: classification,
@@ -25,9 +25,9 @@ description: Execute a project's actual migration from flat central/index files
 
 - `pm-pdata-do-audit-and-prepare-to-migrate` - readiness audit. Finds and fixes problems in the CURRENT flat files.
   Produces a readiness manifest. Does not touch pdata at all.
-- `pm-pdata-schema-design` - designs the TARGET record-group schema in the abstract (field names,
+- `pm-pdata-design-schema` - designs the TARGET record-group schema in the abstract (field names,
   types, groupings) before any data moves.
-- `pm-pdata-do-migrate` (this skill) - takes whatever schema exists (designed via the skill above,
+- `pm-pdata-do-manual-migration` (this skill) - takes whatever schema exists (designed via the skill above,
   or designed inline as part of this skill's own plan if no separate design session happened) and
   actually moves the data: `ccst pdata add`/`batch` calls, verification, and a results record.
 
@@ -59,7 +59,7 @@ audit pass would.
 
 ## Step 2: design or confirm the target schema
 
-For each central file being migrated, decide (or confirm, if `pm-pdata-schema-design` already
+For each central file being migrated, decide (or confirm, if `pm-pdata-design-schema` already
 ran):
 
 - **Record group name** - typically the file's own conceptual name (`correspondence-log`,

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-conflict-resolution → cc_session_tools-3.3.1/src/cc_session_tools/skills/pm-pdata-resolve-conflicts}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pm-pdata-conflict-resolution
+name: pm-pdata-resolve-conflicts
 description: Use immediately when `ccst pdata update` or `ccst pdata delete` exits 3 (a version conflict) - takes the CLI's current-vs-attempted diff and presents it to Chris for reconciliation, per spec §6.2's "the session asks Chris how to reconcile" contract. Also use when `ccst pdata resolve` reports a cross-machine fork (a `.pdata-db-dump` conflict between two laptops), or phrasing like "pdata update conflict", "version conflict on a record", "someone else already updated this row", "sync conflict", "pdata fork between machines". Never auto-retries, never silently picks a side, never discards either version.
 ---
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools/skills/pm-project-init/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pm-project-init
-description: Use when initializing a brand-new project's ccst pdata store, or migrating an existing ~/cc/<project>'s informally-accumulated flat files into it - drives `ccst pdata init` and applies judgement reviewing its classification report (spec §3's folder-owned/db-owned framework), since the tool's own defaults are deliberately conservative and need a human decision on every ambiguous file. Triggers - "migrate <project> to pdata", "run pdata init for <project>", "set up the data store for <project>", "/pm-project-init". Do NOT use for ccst pdata verify, per-record-group schema design (pm-pdata-schema-design), or version-conflict reconciliation (pm-pdata-conflict-resolution) - those are separate skills.
+description: Use when initializing a brand-new project's ccst pdata store, or migrating an existing ~/cc/<project>'s informally-accumulated flat files into it - drives `ccst pdata init` and applies judgement reviewing its classification report (spec §3's folder-owned/db-owned framework), since the tool's own defaults are deliberately conservative and need a human decision on every ambiguous file. Triggers - "migrate <project> to pdata", "run pdata init for <project>", "set up the data store for <project>", "/pm-project-init". Do NOT use for ccst pdata verify, per-record-group schema design (pm-pdata-design-schema), or version-conflict reconciliation (pm-pdata-resolve-conflicts) - those are separate skills.
 ---
 
 # pm-project-init

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools/skills/pm-project-layout-reference/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pm-project-layout-reference
-description: Canonical reference for ~/cc/<project>'s optional folder conventions (correspondence/, meetings-and-calls/, analysis/, workstreams/, workstreams-archived/) and the assessment criteria for using them - which folders a given project needs, when correspondence/ should nest by year, and how a workstream moves from active to archived. Read this before setting up a new project's folders, before reorganising an existing project's layout, or before deciding whether a project's correspondence/ needs splitting. Reference-only - does not perform any reorganisation itself; for an actual flat-to-nested split once you've decided one is needed, see `ccst pdata reorganize`. Triggers - "how should this project be organised", "should correspondence/ be split", "archive this workstream", "/pm-project-layout-reference". Do NOT use for the pdata data-store migration itself (pm-project-init) or per-record-group schema design (pm-pdata-schema-design) - those are separate skills; this one is about folder-owned content and structure, not the data store.
+description: Canonical reference for ~/cc/<project>'s optional folder conventions (correspondence/, meetings-and-calls/, analysis/, workstreams/, workstreams-archived/) and the assessment criteria for using them - which folders a given project needs, when correspondence/ should nest by year, and how a workstream moves from active to archived. Read this before setting up a new project's folders, before reorganising an existing project's layout, or before deciding whether a project's correspondence/ needs splitting. Reference-only - does not perform any reorganisation itself; for an actual flat-to-nested split once you've decided one is needed, see `ccst pdata reorganize`. Triggers - "how should this project be organised", "should correspondence/ be split", "archive this workstream", "/pm-project-layout-reference". Do NOT use for the pdata data-store migration itself (pm-project-init) or per-record-group schema design (pm-pdata-design-schema) - those are separate skills; this one is about folder-owned content and structure, not the data store.
 ---
 
 # pm-project-layout-reference

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1/src/cc_session_tools.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.0
+Version: 3.3.1
 Summary: Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)
 Author: raffishquartan
 License: MIT License

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/src/cc_session_tools.egg-info/SOURCES.txt

@@ -123,10 +123,10 @@ src/cc_session_tools/skills/move-session/SKILL.md
 src/cc_session_tools/skills/move-session/hooks/sessionstart-pending-rename.sh
 src/cc_session_tools/skills/move-session/scripts/cc_session_rules.py
 src/cc_session_tools/skills/move-session/scripts/move_session.py
-src/cc_session_tools/skills/pm-pdata-conflict-resolution/SKILL.md
+src/cc_session_tools/skills/pm-pdata-design-schema/SKILL.md
 src/cc_session_tools/skills/pm-pdata-do-audit-and-prepare-to-migrate/SKILL.md
-src/cc_session_tools/skills/pm-pdata-do-migrate/SKILL.md
-src/cc_session_tools/skills/pm-pdata-schema-design/SKILL.md
+src/cc_session_tools/skills/pm-pdata-do-manual-migration/SKILL.md
+src/cc_session_tools/skills/pm-pdata-resolve-conflicts/SKILL.md
 src/cc_session_tools/skills/pm-project-init/SKILL.md
 src/cc_session_tools/skills/pm-project-layout-reference/SKILL.md
 src/cc_session_tools/skills/pm-update-central-files/SKILL.md

{cc_session_tools-3.3.0 → cc_session_tools-3.3.1}/tests/test_ccst_bundle_discovery.py

@@ -140,17 +140,18 @@ def test_bundled_prompts_are_no_longer_placeholders():
         assert "PLACEHOLDER" not in text
 
 
-def test_pm_pdata_audit_and_migrate_are_bundled_skills():
-    """pm-pdata-do-audit-and-prepare-to-migrate and pm-pdata-do-migrate (renamed from
-    pm-pdata-audit/pm-pdata-migrate in 3.1.0 for clarity) were built directly under
-    ~/.claude/skills/ in an earlier session - moved into this repo's bundled skills/ so
-    ccst skills install / install-everything provision them on every machine, not just the
-    one they were authored on. No registry to update - _discover_skills is a directory scan
-    (any subdir with a SKILL.md), so this test is really asserting the directories/files
+def test_pm_pdata_audit_and_manual_migration_are_bundled_skills():
+    """pm-pdata-do-audit-and-prepare-to-migrate and pm-pdata-do-manual-migration (renamed from
+    pm-pdata-audit/pm-pdata-migrate in 3.1.0, then pm-pdata-do-migrate renamed again to
+    pm-pdata-do-manual-migration for clarity once it became a deprecated fallback) were built
+    directly under ~/.claude/skills/ in an earlier session - moved into this repo's bundled
+    skills/ so ccst skills install / install-everything provision them on every machine, not
+    just the one they were authored on. No registry to update - _discover_skills is a directory
+    scan (any subdir with a SKILL.md), so this test is really asserting the directories/files
     exist and are named correctly."""
     discovered = {p.name for p in ccst._discover_skills(ccst._discover_source_dir())}
     assert "pm-pdata-do-audit-and-prepare-to-migrate" in discovered
-    assert "pm-pdata-do-migrate" in discovered
+    assert "pm-pdata-do-manual-migration" in discovered
 
 
 def test_compact_smart_is_a_bundled_skill():