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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.1
+Version: 3.3.2
 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.1 → cc_session_tools-3.3.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "cc-session-tools"
-version = "3.3.1"
+version = "3.3.2"
 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.1 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/classify.py

@@ -8,7 +8,7 @@ apart by a generic scan; guessing wrong here would silently bake a per-project
 judgement call into shared tooling, which this plan must not do (see the
 per-project inventory doc, not this module, for those calls). Every markdown/
 text/unknown-extension file defaults to folder-owned; a human (via the
-pm-project-init skill) reviews the printed report and flips individual entries
+pm-pdata-do-init skill) reviews the printed report and flips individual entries
 to db-owned with an explicit record_group/strategy.
 """
 from __future__ import annotations

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/cutover.py

@@ -14,7 +14,7 @@ from cc_session_tools.lib.pdata.manifest import ManifestEntry
 def _pointer_file_content(*, project: str, entry: ManifestEntry) -> str:
     """Generic pointer content (spec pdata/init-pointer-files): the record_group now
     holding this file's data, its field/schema table, and an example query — plus,
-    when the entry carries preface_text (set by hand per pm-project-init's
+    when the entry carries preface_text (set by hand per pm-pdata-do-init's
     garbled-CSV-header fix recipe), that text verbatim under its own heading."""
     lines = [
         f"# {Path(entry.path).name} — migrated to pdata",

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/importers.py

@@ -89,7 +89,7 @@ def import_json_array_rows(project_root: Path, entry: ManifestEntry) -> list[Imp
     path = project_root / entry.path
     created_at = _mtime(path)
     data: Any = json.loads(path.read_text(encoding="utf-8"))
-    # A hand-edited manifest entry (pm-project-init Step 4 instructs editing this
+    # A hand-edited manifest entry (pm-pdata-do-init Step 4 instructs editing this
     # file directly) can assign 'json-array-rows' to a file whose actual JSON
     # shape isn't an array of objects. Validate the shape here and raise
     # ValueError — the exact exception type write()'s per-entry

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/init_service.py

@@ -136,7 +136,7 @@ def _render_report(m: Manifest) -> str:
                 lines.append(
                     "    ⚠ worth double-checking — these field names read as sentence "
                     "fragments, not column names; this file's header may not be what it "
-                    "looks like (see pm-project-init's garbled-CSV-header caveat)"
+                    "looks like (see pm-pdata-do-init's garbled-CSV-header caveat)"
                 )
     lines.append(
         "Review/override entries in the proposal file listed below before running --write."

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/manifest.py

@@ -44,7 +44,7 @@ class ManifestEntry:
     # --write skips any entry that already carries one instead of re-importing it
     # (spec pdata/init-write-idempotency). None for an entry never yet migrated.
     migrated_at: str | None = None
-    # Hand-set during review (pm-project-init's garbled-CSV-header fix recipe):
+    # Hand-set during review (pm-pdata-do-init's garbled-CSV-header fix recipe):
     # header/provenance text stripped from the source file before migration,
     # preserved verbatim here so cutover.archive_entries can carry it into the
     # entry's pointer file (spec pdata/init-pointer-files). None when not applicable.
@@ -95,7 +95,7 @@ def load(path: Path) -> Manifest:
     """Raises ValueError (never a raw KeyError/TypeError/AttributeError) for any
     malformed proposal file — a missing "project"/"entries" key, an "entries" that
     isn't a list, an entry that isn't an object, or an entry with an unexpected
-    field shape. This is a real hand-edit surface (pm-project-init Step 4
+    field shape. This is a real hand-edit surface (pm-pdata-do-init Step 4
     instructs editing this file directly), so a shape error here must reach
     _cmd_pdata_init's `except (FileNotFoundError, ValueError)` and dry_run's
     `except ValueError` and produce the documented exit-2 validation error instead

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/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-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.
+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-pdata-do-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-manual-migration`
+> `pm-pdata-do-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.
 
@@ -140,7 +140,7 @@ This file is deliberately NOT a migration plan - it's a findings list for whoeve
 `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)
+## Phase 5: write the readiness manifest (for `ccst pdata init`/`pm-pdata-do-init` to consume)
 
 Once the audit reaches a settled state (per your own stopping rule - typically two consecutive
 clean verification rounds, or a documented pragmatic stop), write one machine-and-human-readable
@@ -151,7 +151,7 @@ otherwise the project's own top-level docs location. Its existence and location
 recorded in the project's own instructions file (`CLAUDE.md`/`AGENTS.md`/equivalent) so a future
 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`
+The manifest must have, in this order, so a `pm-pdata-do-init` session running `ccst pdata init`
 (or, for the narrow record shapes it can't express, the deprecated `pm-pdata-do-manual-migration`
 fallback) can parse it deterministically:
 
@@ -162,7 +162,7 @@ fallback) can parse it deterministically:
    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-design-schema` and
-   `pm-project-init` expect to consume - this is the same content this skill's own Phase 4
+   `pm-pdata-do-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
    single files, machine-specific paths, null-value conventions that aren't real nulls.

{cc_session_tools-3.3.1/src/cc_session_tools/skills/pm-project-init → cc_session_tools-3.3.2/src/cc_session_tools/skills/pm-pdata-do-init}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-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-design-schema), or version-conflict reconciliation (pm-pdata-resolve-conflicts) - those are separate skills.
+name: pm-pdata-do-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-pdata-do-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
+# pm-pdata-do-init
 
 Drives `ccst pdata init` (spec §7) end to end and applies the judgement the tool itself
 deliberately does not: `ccst pdata init`'s automatic classifier only proposes CSV/JSON files as

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

@@ -6,7 +6,7 @@ description: Execute a project's actual migration from flat central/index files
 # 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,
+> (driven by the `pm-pdata-do-init` skill) is the tool-native migration mechanism: classification,
 > a human-reviewable manifest, backup, verify, atomic cutover, and shipped post-write doc/skill-
 > update prompts. It is the default choice wherever it is available, and this skill is superseded
 > by it for any file `ccst pdata init`'s classifier can already handle (a normal CSV/JSON file

{cc_session_tools-3.3.1 → cc_session_tools-3.3.2}/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-design-schema) - 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-pdata-do-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
@@ -64,7 +64,7 @@ These criteria apply to any of the folders above, not just `correspondence/`:
 
 These five folders hold folder-owned content by definition - genuinely file-shaped material
 (attachments, PDFs, `.eml` originals) that isn't a good fit for becoming pdata rows. A project
-being pdata-migrated (see `pm-project-init`) says nothing about whether it also has any of these
+being pdata-migrated (see `pm-pdata-do-init`) says nothing about whether it also has any of these
 five folders, and vice versa - they're orthogonal. `home` is the concrete example: it's
 pdata-migrated (its structured data now lives in SQLite) and still has a live `correspondence/`
 folder full of `.md`+`.pdf` pairs, untouched by the migration, sitting right next to its `data/`

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.1
+Version: 3.3.2
 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.1 → cc_session_tools-3.3.2}/src/cc_session_tools.egg-info/SOURCES.txt

@@ -125,9 +125,9 @@ 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-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-init/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
 src/cc_session_tools/skills/reduce-persistent-context/CALIBRATION.md