@blxzer/pactile 0.5.0 → 0.6.0-beta.2

package/dist/commands/init.js

@@ -8,13 +8,12 @@ import figlet from "figlet";
 import inquirer from "inquirer";
 import { createWorkflowStructure } from "../configurators/workflow.js";
 import { getInitToolChoices } from "../configurators/index.js";
-import { getPythonCommandForPlatform, setResolvedPythonCommand, } from "../configurators/shared.js";
 import { DIR_NAMES, FILE_NAMES, PATHS } from "../constants/paths.js";
 import { VERSION } from "../constants/version.js";
 import { setWriteMode, startRecordingWrites, stopRecordingWrites, } from "../utils/file-writer.js";
-import { applyKernelCreate, applyKernelStart, writeWaveCConfirmed, } from "@blxzer/pactile-core/task";
-import { PACTILE_ENVIRONMENT_KEYS, readPactileEnvironment, } from "@blxzer/pactile-core";
+import { applyKernelCreate, applyKernelStart, writeWaveCConfirmed, } from "../core/task/index.js";
 import { emptyTaskJson } from "../utils/task-json.js";
+import { initializeDeveloper, readDeveloper } from "../utils/developer.js";
 import { detectProjectType, detectMonorepo, sanitizePkgName, } from "../utils/project-detector.js";
 import { initializeHashes, removeHash } from "../utils/template-hash.js";
 import { NATIVE_WORKFLOW_ID, resolveWorkflowTemplate, } from "../utils/workflow-resolver.js";
@@ -26,141 +25,6 @@ import { getProjectCapability, getProjectCapabilityChoices, loadProjectCapabilit
 import { collectCanonicalGenerationFiles, collectLegacyCstlLifecycleFiles, discoverCanonicalGenerationPaths, installedPactilePlatforms, materializeCanonicalGeneration, materializePreparedLegacyUserState, prepareLegacyCstlImport, readLegacyCstlVersion, runLifecycleCommand, seedCanonicalBuildRoot, } from "../pactile/lifecycle/index.js";
 import { InstallStateStore } from "../pactile/runtime/stores.js";
 import { inspectLegacyInitContext, legacyImportPreparedMessage, } from "../pactile/compat/init-context.js";
-const MIN_PYTHON_MAJOR = 3;
-const MIN_PYTHON_MINOR = 9;
-const PYTHON_VERSION_RE = /Python (\d+)\.(\d+)/;
-export function isSupportedPythonVersion(versionOutput) {
-    const match = versionOutput.match(PYTHON_VERSION_RE);
-    if (!match)
-        return false;
-    const major = Number(match[1]);
-    const minor = Number(match[2]);
-    return (major > MIN_PYTHON_MAJOR ||
-        (major === MIN_PYTHON_MAJOR && minor >= MIN_PYTHON_MINOR));
-}
-function detectPythonVersion(command) {
-    try {
-        return execSync(`${command} --version`, {
-            encoding: "utf-8",
-            stdio: "pipe",
-        }).trim();
-    }
-    catch (err) {
-        const code = err?.code;
-        if (code === "EPERM" || code === "EACCES") {
-            return "sandbox-restricted";
-        }
-        return null;
-    }
-}
-export function requireSupportedPython(command) {
-    // Final escape hatch — set when the user knows python3 is on PATH but
-    // the probe keeps failing for environment-specific reasons.
-    if (readPactileEnvironment(PACTILE_ENVIRONMENT_KEYS.skipPythonCheck) === "1") {
-        return `version check skipped (PACTILE_SKIP_PYTHON_CHECK=1)`;
-    }
-    const versionOutput = detectPythonVersion(command);
-    if (versionOutput === "sandbox-restricted") {
-        console.warn(chalk.yellow(`⚠ Python version check skipped — sandboxed environment blocked ` +
-            `child_process spawn (EPERM/EACCES). Assuming "${command}" is on ` +
-            `PATH. If init fails later, re-run on the host or set ` +
-            `PACTILE_SKIP_PYTHON_CHECK=1.`));
-        return `version unknown (sandbox-restricted)`;
-    }
-    if (!versionOutput) {
-        throw new Error(`Python command "${command}" not found. Pactile init requires Python ≥ 3.9.`);
-    }
-    if (!isSupportedPythonVersion(versionOutput)) {
-        throw new Error(`${versionOutput} detected via "${command}", but Pactile init requires Python ≥ 3.9.`);
-    }
-    return versionOutput;
-}
-/**
- * Candidate Python command list per platform.
- *
- * Windows: `python` is the usual python.org installer choice, but Microsoft
- * Store ships `python3`, and the `py` launcher is `py -3`. We try all three
- * before giving up — fixes #236 where users with only `python3` (not
- * `python`) had `pactile init` fail outright.
- *
- * Non-Windows: `python3` is canonical; `python` is a fallback for systems
- * where Python 3 is the only Python and is named `python` (some Arch
- * configs, conda envs).
- */
-const PYTHON_CANDIDATES = {
-    win32: ["python", "python3", "py -3"],
-    other: ["python3", "python"],
-};
-/**
- * Detect a working Python ≥ 3.9 command on the host platform.
- *
- * Honors `PACTILE_PYTHON_CMD` (explicit override, no probe) and
- * `PACTILE_SKIP_PYTHON_CHECK=1` (skip probe, trust platform default).
- *
- * Otherwise tries each candidate in `PYTHON_CANDIDATES` in order and returns
- * the first whose `--version` matches `Python ≥ 3.9`. Caches the result via
- * `setResolvedPythonCommand` so all downstream template / configurator
- * writes pick up the resolved value.
- *
- * Throws a helpful, Windows-aware error if no candidate works.
- */
-export function resolveSupportedPython() {
-    // Explicit override — user knows their environment.
-    const override = readPactileEnvironment(PACTILE_ENVIRONMENT_KEYS.pythonCommand)?.trim();
-    if (override) {
-        setResolvedPythonCommand(override);
-        return { command: override, version: "set via PACTILE_PYTHON_CMD" };
-    }
-    // Skip probe entirely.
-    if (readPactileEnvironment(PACTILE_ENVIRONMENT_KEYS.skipPythonCheck) === "1") {
-        const fallback = getPythonCommandForPlatform();
-        setResolvedPythonCommand(fallback);
-        return {
-            command: fallback,
-            version: "version check skipped (PACTILE_SKIP_PYTHON_CHECK=1)",
-        };
-    }
-    const candidates = process.platform === "win32"
-        ? PYTHON_CANDIDATES.win32
-        : PYTHON_CANDIDATES.other;
-    const probeFailures = [];
-    for (const candidate of candidates) {
-        const probe = detectPythonVersion(candidate);
-        if (probe === "sandbox-restricted") {
-            console.warn(chalk.yellow(`⚠ Python version check skipped — sandboxed environment blocked ` +
-                `child_process spawn (EPERM/EACCES). Assuming "${candidate}" is ` +
-                `on PATH. If init fails later, re-run on the host or set ` +
-                `PACTILE_SKIP_PYTHON_CHECK=1.`));
-            setResolvedPythonCommand(candidate);
-            return {
-                command: candidate,
-                version: "version unknown (sandbox-restricted)",
-            };
-        }
-        if (!probe) {
-            probeFailures.push(`${candidate}: not found`);
-            continue;
-        }
-        if (!isSupportedPythonVersion(probe)) {
-            probeFailures.push(`${candidate}: ${probe} (< 3.9)`);
-            continue;
-        }
-        setResolvedPythonCommand(candidate);
-        return { command: candidate, version: probe };
-    }
-    const isWindows = process.platform === "win32";
-    const installHint = isWindows
-        ? `Install Python ≥ 3.9 from https://www.python.org/downloads/windows/ — make sure ` +
-            `"Add Python to PATH" is checked in the installer. Or, if Python is ` +
-            `installed under a different name, set PACTILE_PYTHON_CMD=<your-cmd> ` +
-            `before re-running init (e.g. \`set PACTILE_PYTHON_CMD=py -3\`).`
-        : `Install Python ≥ 3.9 from https://www.python.org/downloads/ or via your ` +
-            `package manager. Or set PACTILE_PYTHON_CMD=<your-cmd> before re-running.`;
-    throw new Error(`No supported Python command found. Tried: ${candidates.join(", ")}.\n` +
-        `Probe results:\n  ${probeFailures.join("\n  ")}\n\n` +
-        `Pactile init requires Python ≥ 3.9. ${installHint}\n` +
-        `Last-resort escape hatch: set PACTILE_SKIP_PYTHON_CHECK=1 to skip the probe entirely.`);
-}
 // =============================================================================
 // Bootstrap Task Creation
 // =============================================================================
@@ -222,8 +86,7 @@ function writeTaskSkeleton(cwd, taskName, taskJson, prdContent) {
  * Compute the bootstrap checklist items (previously stored as structured
  * `subtasks: [{name, status}]` in task.json). Per task 04-21-task-schema-unify
  * (D1), these live as markdown `- [ ]` items in prd.md instead, so task.json
- * stays canonical with `subtasks: string[]` (child task dir names, same as
- * task_store.py).
+ * stays canonical with `subtasks: string[]` (child task dir names).
  */
 function getBootstrapChecklistItems(projectType, packages) {
     if (packages && packages.length > 0) {
@@ -253,25 +116,25 @@ function renderCapabilityReadinessSection(selectedCapabilities) {
         return `- [ ] \`${capability.id}\` — ${capability.title}. Verify the generated MCP/config path is usable before claiming it in task evidence.`;
     })
         .join("\n");
-    return `
-## Capability readiness (required before archive)
-
-Init selected optional project capabilities for this repo. Treat them as
-\`pending\` until you verify they work in this checkout.
-
-${checklist}
-
-- Read \`.pactile/capabilities.json\` / \`.pactile/capabilities.md\` and keep the
-  readiness state honest: \`pending\`, \`ready\`, or \`failed\`.
-- For \`codebase-retrieval\`, verify \`.codegraph/\` exists (or initialize it)
-  and confirm the MCP path is usable. After the first index, CodeGraph's file
-  watcher auto-syncs later edits; you do not need to re-run full indexing for
-  every code change.
-- If a capability cannot be made ready, record the failure and fallback path in
-  \`verify.md\` before archiving bootstrap.
-- Validation entrypoint: \`pactile capability-smoke --write-status\`
-
----
+    return `
+## Capability readiness (required before archive)
+
+Init selected optional project capabilities for this repo. Treat them as
+\`pending\` until you verify they work in this checkout.
+
+${checklist}
+
+- Read \`.pactile/capabilities.json\` / \`.pactile/capabilities.md\` and keep the
+  readiness state honest: \`pending\`, \`ready\`, or \`failed\`.
+- For \`codebase-retrieval\`, verify \`.codegraph/\` exists (or initialize it)
+  and confirm the MCP path is usable. After the first index, CodeGraph's file
+  watcher auto-syncs later edits; you do not need to re-run full indexing for
+  every code change.
+- If a capability cannot be made ready, record the failure and fallback path in
+  \`verify.md\` before archiving bootstrap.
+- Validation entrypoint: \`pactile capability-smoke --write-status\`
+
+---
 `;
 }
 function getBootstrapRelatedFiles(projectType, packages) {
@@ -286,145 +149,146 @@ function getBootstrapRelatedFiles(projectType, packages) {
     }
     return [".pactile/spec/backend/", ".pactile/spec/frontend/"];
 }
-function getBootstrapPrdContent(projectType, pythonCmd, selectedCapabilities, packages) {
+function getBootstrapPrdContent(projectType, selectedCapabilities, packages) {
     const checklistItems = getBootstrapChecklistItems(projectType, packages);
     const checklistMarkdown = checklistItems
         .map((item) => `- [ ] ${item}`)
         .join("\n");
-    const header = `# Bootstrap Task: Fill Project Development Guidelines
-
-**You (the AI) are running this task. The developer does not read this file.**
-
-The developer just ran \`pactile init\` on this project for the first time.
-\`.pactile/\` now exists with empty spec scaffolding, and this bootstrap task
-exists under \`.pactile/tasks/\`. When they want to work on it, they should start
-this task from a session that provides Pactile session identity.
-
-**Your job**: help them populate \`.pactile/spec/\` with the team's real
-coding conventions. Every future AI session — this project's
-\`pactile-implement\` and \`pactile-check\` sub-agents — auto-loads spec files
-listed in per-task jsonl manifests. Empty spec = sub-agents write generic
-code. Real spec = sub-agents match the team's actual patterns.
-
-Don't dump instructions. Open with a short greeting, figure out if the repo
-has any existing convention docs (AGENTS.md, .cursorrules, CONTRIBUTING.md, etc.), and drive
-the rest conversationally.
-
----
-
-## Status (update the checkboxes as you complete each item)
-
-${checklistMarkdown}
-
----
-
-${renderCapabilityReadinessSection(selectedCapabilities)}
-
-## Spec files to populate
+    const header = `# Bootstrap Task: Fill Project Development Guidelines
+
+**You (the AI) are running this task. The developer does not read this file.**
+
+The developer just ran \`pactile init\` on this project for the first time.
+\`.pactile/\` now exists with empty spec scaffolding, and this bootstrap task
+exists under \`.pactile/tasks/\`. When they want to work on it, they should start
+this task from a session that provides Pactile session identity.
+
+**Your job**: help them populate \`.pactile/spec/\` with the team's real
+coding conventions. Every future AI session — this project's
+\`pactile-implement\` and \`pactile-check\` sub-agents — auto-loads spec files
+listed in per-task jsonl manifests. Empty spec = sub-agents write generic
+code. Real spec = sub-agents match the team's actual patterns.
+
+Don't dump instructions. Open with a short greeting, figure out if the repo
+has any existing convention docs (AGENTS.md, .cursorrules, CONTRIBUTING.md, etc.), and drive
+the rest conversationally.
+
+---
+
+## Status (update the checkboxes as you complete each item)
+
+${checklistMarkdown}
+
+---
+
+${renderCapabilityReadinessSection(selectedCapabilities)}
+
+## Spec files to populate
 `;
-    const backendSection = `
-
-### Backend guidelines
-
-| File | What to document |
-|------|------------------|
-| \`.pactile/spec/backend/directory-structure.md\` | Where different file types go (routes, services, utils) |
-| \`.pactile/spec/backend/database-guidelines.md\` | ORM, migrations, query patterns, naming conventions |
-| \`.pactile/spec/backend/error-handling.md\` | How errors are caught, logged, and returned |
-| \`.pactile/spec/backend/logging-guidelines.md\` | Log levels, format, what to log |
-| \`.pactile/spec/backend/quality-guidelines.md\` | Code review standards, testing requirements |
+    const backendSection = `
+
+### Backend guidelines
+
+| File | What to document |
+|------|------------------|
+| \`.pactile/spec/backend/directory-structure.md\` | Where different file types go (routes, services, utils) |
+| \`.pactile/spec/backend/database-guidelines.md\` | ORM, migrations, query patterns, naming conventions |
+| \`.pactile/spec/backend/error-handling.md\` | How errors are caught, logged, and returned |
+| \`.pactile/spec/backend/logging-guidelines.md\` | Log levels, format, what to log |
+| \`.pactile/spec/backend/quality-guidelines.md\` | Code review standards, testing requirements |
 `;
-    const frontendSection = `
-
-### Frontend guidelines
-
-| File | What to document |
-|------|------------------|
-| \`.pactile/spec/frontend/directory-structure.md\` | Component/page/hook organization |
-| \`.pactile/spec/frontend/component-guidelines.md\` | Component patterns, props conventions |
-| \`.pactile/spec/frontend/hook-guidelines.md\` | Custom hook naming, patterns |
-| \`.pactile/spec/frontend/state-management.md\` | State library, patterns, what goes where |
-| \`.pactile/spec/frontend/type-safety.md\` | TypeScript conventions, type organization |
-| \`.pactile/spec/frontend/quality-guidelines.md\` | Linting, testing, accessibility |
+    const frontendSection = `
+
+### Frontend guidelines
+
+| File | What to document |
+|------|------------------|
+| \`.pactile/spec/frontend/directory-structure.md\` | Component/page/hook organization |
+| \`.pactile/spec/frontend/component-guidelines.md\` | Component patterns, props conventions |
+| \`.pactile/spec/frontend/hook-guidelines.md\` | Custom hook naming, patterns |
+| \`.pactile/spec/frontend/state-management.md\` | State library, patterns, what goes where |
+| \`.pactile/spec/frontend/type-safety.md\` | TypeScript conventions, type organization |
+| \`.pactile/spec/frontend/quality-guidelines.md\` | Linting, testing, accessibility |
 `;
-    const footer = `
-
-### Thinking guides (already populated)
-
-\`.pactile/spec/guides/\` contains general thinking guides pre-filled with
-best practices. Customize only if something clearly doesn't fit this project.
-
----
-
-## How to fill the spec
-
-### Step 1: Import from existing convention files first (preferred)
-
-Search the repo for existing convention docs. If any exist, read them and
-extract the relevant rules into the matching \`.pactile/spec/\` files —
-usually much faster than documenting from scratch.
-
-| File / Directory | Notes |
-|------|------|
-| \`AGENTS.md\` | Agent entry / managed instructions |
-| \`.cursorrules\` | Legacy Cursor rules file |
-| \`.cursor/rules/*.mdc\` | Cursor rules directory |
-| \`CONTRIBUTING.md\` | General project conventions |
-| \`.editorconfig\` | Editor formatting rules |
-
-### Step 2: Analyze the codebase for anything not covered by existing docs
-
-Scan real code to discover patterns. Before writing each spec file:
-- Find 2-3 real examples of each pattern in the codebase.
-- Reference real file paths (not hypothetical ones).
-- Document anti-patterns the team clearly avoids.
-
-### Step 3: Document reality, not ideals
-
-**Critical**: write what the code *actually does*, not what it should do.
-Sub-agents match the spec, so aspirational patterns that don't exist in the
-codebase will cause sub-agents to write code that looks out of place.
-
-If the team has known tech debt, document the current state — improvement
-is a separate conversation, not a bootstrap concern.
-
----
-
-## Quick explainer of the runtime (share when they ask "why do we need spec at all")
-
-- Every AI coding task spawns two sub-agents: \`pactile-implement\` (writes
-  code) and \`pactile-check\` (verifies quality).
-- Each task has \`implement.jsonl\` / \`check.jsonl\` manifests listing which
-  spec files to load.
-- The platform hook auto-injects those spec files + the task's \`prd.md\`
-  into every sub-agent prompt, so the sub-agent codes/reviews per team
-  conventions without anyone pasting them manually.
-- Source of truth: \`.pactile/spec/\`. That's why filling it well now pays
-  off forever.
-
----
-
-## Completion
-
-When the developer confirms the checklist items above are done with real
-examples (not placeholders), guide them to run:
-
-\`\`\`bash
-${pythonCmd} ./.pactile/scripts/task.py archive 00-bootstrap-guidelines
-\`\`\`
-
-After archive, every new developer who joins this project will get a
-\`00-join-<slug>\` onboarding task instead of this bootstrap task.
-
----
-
-## Suggested opening line
-
-"Welcome to Pactile! Your init just set me up to help you fill the project
-spec — a one-time setup so every future AI session follows the team's
-conventions instead of writing generic code. Before we start, do you have
-any existing convention docs (AGENTS.md, .cursorrules, CONTRIBUTING.md,
-etc.) I can pull from, or should I scan the codebase from scratch?"
+    const footer = `
+
+### Thinking guides (already populated)
+
+\`.pactile/spec/guides/\` contains general thinking guides pre-filled with
+best practices. Customize only if something clearly doesn't fit this project.
+
+---
+
+## How to fill the spec
+
+### Step 1: Import from existing convention files first (preferred)
+
+Search the repo for existing convention docs. If any exist, read them and
+extract the relevant rules into the matching \`.pactile/spec/\` files —
+usually much faster than documenting from scratch.
+
+| File / Directory | Notes |
+|------|------|
+| \`AGENTS.md\` | Agent entry / managed instructions |
+| \`.cursorrules\` | Legacy Cursor rules file |
+| \`.cursor/rules/*.mdc\` | Cursor rules directory |
+| \`CONTRIBUTING.md\` | General project conventions |
+| \`.editorconfig\` | Editor formatting rules |
+
+### Step 2: Analyze the codebase for anything not covered by existing docs
+
+Scan real code to discover patterns. Before writing each spec file:
+- Find 2-3 real examples of each pattern in the codebase.
+- Reference real file paths (not hypothetical ones).
+- Document anti-patterns the team clearly avoids.
+
+### Step 3: Document reality, not ideals
+
+**Critical**: write what the code *actually does*, not what it should do.
+Sub-agents match the spec, so aspirational patterns that don't exist in the
+codebase will cause sub-agents to write code that looks out of place.
+
+If the team has known tech debt, document the current state — improvement
+is a separate conversation, not a bootstrap concern.
+
+---
+
+## Quick explainer of the runtime (share when they ask "why do we need spec at all")
+
+- Every AI coding task spawns two sub-agents: \`pactile-implement\` (writes
+  code) and \`pactile-check\` (verifies quality).
+- Each task has \`implement.jsonl\` / \`check.jsonl\` manifests listing which
+  spec files to load.
+- The platform hook auto-injects those spec files + the task's \`prd.md\`
+  into every sub-agent prompt, so the sub-agent codes/reviews per team
+  conventions without anyone pasting them manually.
+- Source of truth: \`.pactile/spec/\`. That's why filling it well now pays
+  off forever.
+
+---
+
+## Completion
+
+When the developer confirms the checklist items above are done with real
+examples (not placeholders), guide them to run:
+
+\`\`\`bash
+pactile task archive 00-bootstrap-guidelines --check
+pactile task archive 00-bootstrap-guidelines
+\`\`\`
+
+After archive, every new developer who joins this project will get a
+\`00-join-<slug>\` onboarding task instead of this bootstrap task.
+
+---
+
+## Suggested opening line
+
+"Welcome to Pactile! Your init just set me up to help you fill the project
+spec — a one-time setup so every future AI session follows the team's
+conventions instead of writing generic code. Before we start, do you have
+any existing convention docs (AGENTS.md, .cursorrules, CONTRIBUTING.md,
+etc.) I can pull from, or should I scan the codebase from scratch?"
 `;
     let content = header;
     if (packages && packages.length > 0) {
@@ -480,9 +344,9 @@ function getBootstrapTaskJson(developer, projectType, packages) {
 /**
  * Create bootstrap task for first-time setup
  */
-function createBootstrapTask(cwd, developer, pythonCmd, projectType, selectedCapabilities, packages) {
+function createBootstrapTask(cwd, developer, projectType, selectedCapabilities, packages) {
     const taskJson = getBootstrapTaskJson(developer, projectType, packages);
-    const prdContent = getBootstrapPrdContent(projectType, pythonCmd, selectedCapabilities, packages);
+    const prdContent = getBootstrapPrdContent(projectType, selectedCapabilities, packages);
     return writeTaskSkeleton(cwd, BOOTSTRAP_TASK_NAME, taskJson, prdContent);
 }
 // =============================================================================
@@ -513,7 +377,7 @@ function getJoinerTaskJson(developer, taskName) {
  * PRD content for joiner onboarding. Kept concise (~80 lines) — deeper
  * guidance lives in skills and docs.
  */
-function getJoinerPrdContent(developer, pythonCmd, selectedCapabilities) {
+function getJoinerPrdContent(developer, selectedCapabilities) {
     const slug = slugifyDeveloperName(developer);
     const selectedCapabilityChecklist = selectedCapabilities
         .map((id) => {
@@ -523,129 +387,115 @@ function getJoinerPrdContent(developer, pythonCmd, selectedCapabilities) {
         .join("\n");
     let capabilitySection = "";
     if (selectedCapabilities.length > 0) {
-        capabilitySection = `
-### 5. Re-verify selected project capabilities
-
-This repo has capability selections recorded in \`.pactile/capabilities.json\`.
-Before they rely on MCP-backed behavior, remind them to check the selected set:
-
-${selectedCapabilityChecklist}
-
-- If a capability is not \`ready\`, have them re-run the local verification path
-  instead of assuming the previous machine's setup carries over.
-
----
+        capabilitySection = `
+### 5. Re-verify selected project capabilities
+
+This repo has capability selections recorded in \`.pactile/capabilities.json\`.
+Before they rely on MCP-backed behavior, remind them to check the selected set:
+
+${selectedCapabilityChecklist}
+
+- If a capability is not \`ready\`, have them re-run the local verification path
+  instead of assuming the previous machine's setup carries over.
+
+---
 `;
     }
-    return `# Joiner Onboarding Task
-
-**You (the AI) are running this task. The developer does not read this file.**
-
-\`${developer}\` just ran \`pactile init\` on a fresh clone, saw "Developer
-initialized", and will now start asking you questions in chat. This joiner task
-exists under \`.pactile/tasks/\`; when they want to work on it, they should
-select it from a session that provides Pactile session identity.
-
-Your job is to orient them to Pactile. Don't dump all of this at them — open
-with a short greeting, ask where they want to start, and fill in the rest as
-they engage.
-
----
-
-## Topics to cover (adapt order to their questions)
-
-### 1. What Pactile is + the workflow
-
-Pactile is a governed capability workspace for Cursor and Codex that keeps AI
-agents consistent with project-specific conventions instead of writing generic
-code every session.
-
-- **Human lifecycle**: Open → Define → Approve → Execute → Verify →
-  (Integrate? when parent-child) → Close. Kernel writes that state.
-  \`.pactile/workflow.md\` is a human overview, **not runtime SSOT**.
-- **Task files** live under \`.pactile/tasks/\`. \`status\` is a projection, not
-  the only truth.
-- **User slash (Native Cursor)**:
-  - \`/pactile-continue\` — resume only when this live session already has a
-    selected task
-  - \`/pactile-finish-work\` — wrap up a finished task
-  - \`/pactile-handoff\` — session handoff to a temp path (not the task's
-    \`handoff.md\`)
-  SessionStart covers entry. \`/pactile-start\` is not installed as a slash on
-  agent-capable Cursor. Official \`/goal\` is not a Pactile Task.
-
-### 2. Runtime mechanics (explain when they ask "how does it know what to do")
-
-- **SessionStart hook** injects identity, git status, selected task, Task
-  Dashboard, and a compiled session pack when Event Bridge subscribers
-  produce one. It must not dump \`workflow.md\` Phase Index as the runtime
-  program.
-- **\`/pactile-continue\`** loads Kernel / Dashboard (or the compiled pack if
-  already in context), reads \`prd.md\` + recent activity, and routes by
-  Kernel human phase. Do **not** treat \`get_context.py --mode phase\` (Phase
-  Index) as runtime SSOT. Internal skills (brainstorm, check, …) are not
-  user slash commands.
-- **Workers**: if this Cursor Task API has no \`pactile-implement\` /
-  \`pactile-check\` enum, dispatch as \`generalPurpose\`. Never label that run
-  \`true-independent\`. When a check worker is available, it follows
-  \`check.jsonl\` — reviews against specs, auto-fixes issues, runs
-  lint/typecheck.
-
-File layout (mention when they ask "where does what live"):
-- \`.pactile/.runtime/sessions/<session>.json\` — live-session selected-task state, gitignored
-- \`.pactile/tasks/<task>/{implement,check}.jsonl\` — per-task context manifests
-- \`.pactile/spec/\` — project-wide conventions (source of truth)
-- \`.pactile/workspace/${developer}/journal-*.md\` — their session log,
-  rotated at ~2000 lines
-
-### 3. This project's actual conventions
-
-- Summarize \`.pactile/spec/\` for them — what coding conventions this
-  specific team enforces.
-- Point at the last 5 entries in \`.pactile/tasks/archive/\` as a rhythm
-  example of how people actually work here. **If archive is empty** (the
-  project just started), skip this — don't invent examples.
-- Not your job in this onboarding to teach them the business code itself —
-  the README and their teammates handle that.
-
-### 4. Their assigned work
-
-- Check if \`.pactile/workspace/${developer}/\` already exists — if yes, it's
-  their journal from another machine and worth mentioning.
-- Run \`${pythonCmd} ./.pactile/scripts/task.py list --assignee ${developer}\` to
-  show tasks assigned to them. (Quote the name if it contains spaces.)
-- Remind them that the "My Tasks" section appears in the SessionStart context
-  on every new session.
-
----
-
-${capabilitySection}
-
-## Optional: walk through a small task end-to-end
-
-If they want to practice before touching real work, offer to pick a tiny
-P3 task or a typo fix and run the full cycle together: \`/pactile-continue\`
-→ implement in Agent → \`/pactile-finish-work\`.
-
----
-
-## Completion
-
-When they feel oriented (or after you've covered the four topics with
-reasonable back-and-forth), guide them to run:
-
-\`\`\`bash
-${pythonCmd} ./.pactile/scripts/task.py archive 00-join-${slug}
-\`\`\`
-
----
-
-## Suggested opening line
-
-"Welcome! Your \`pactile init\` set me up to onboard you to this project. I
-can walk you through the workflow, show you the runtime mechanics under the
-hood, summarize the team's spec, or jump to what you're already curious about
-— which would you prefer?"
+    return `# Joiner Onboarding Task
+
+**You (the AI) are running this task. The developer does not read this file.**
+
+\`${developer}\` just ran \`pactile init\` on a fresh clone, saw "Developer
+initialized", and will now start asking you questions in chat. This joiner task
+exists under \`.pactile/tasks/\`; when they want to work on it, they should
+select it from a session that provides Pactile session identity.
+
+Your job is to orient them to Pactile. Don't dump all of this at them — open
+with a short greeting, ask where they want to start, and fill in the rest as
+they engage.
+
+---
+
+## Topics to cover (adapt order to their questions)
+
+### 1. What Pactile is + the workflow
+
+Pactile is a governed capability workspace for Codex that keeps AI
+agents consistent with project-specific conventions instead of writing generic
+code every session.
+
+- **Human lifecycle**: Open → Define → Approve → Execute → Verify →
+  (Integrate? when parent-child) → Close. Kernel writes that state.
+  \`.pactile/workflow.md\` is a human overview, **not runtime SSOT**.
+- **Task files** live under \`.pactile/tasks/\`. \`status\` is a projection, not
+  the only truth.
+- **Codex session**: read the Task record, project instructions, and current
+  Evidence before resuming. The Task record remains durable authority.
+
+### 2. Runtime mechanics (explain when they ask "how does it know what to do")
+
+- **Context**: load Kernel / Dashboard and the selected Task's \`prd.md\`
+  plus recent activity. Do not treat a generated phase index as runtime
+  authority.
+- **Coordination**: \`pactile codex\` records native desktop task requests and
+  receipts; the App task invokes its native tools. \`pactile pi\` dispatches
+  approved Execute work through Pi RPC.
+
+File layout (mention when they ask "where does what live"):
+- \`.pactile/.runtime/sessions/<session>.json\` — live-session selected-task state, gitignored
+- \`.pactile/tasks/<task>/{implement,check}.jsonl\` — per-task context manifests
+- \`.pactile/spec/\` — project-wide conventions (source of truth)
+- \`.pactile/workspace/${developer}/journal-*.md\` — their session log,
+  rotated at ~2000 lines
+
+### 3. This project's actual conventions
+
+- Summarize \`.pactile/spec/\` for them — what coding conventions this
+  specific team enforces.
+- Point at the last 5 entries in \`.pactile/tasks/archive/\` as a rhythm
+  example of how people actually work here. **If archive is empty** (the
+  project just started), skip this — don't invent examples.
+- Not your job in this onboarding to teach them the business code itself —
+  the README and their teammates handle that.
+
+### 4. Their assigned work
+
+- Check if \`.pactile/workspace/${developer}/\` already exists — if yes, it's
+  their journal from another machine and worth mentioning.
+- Run \`pactile task list --assignee "${developer}"\` to
+  show tasks assigned to them. (Quote the name if it contains spaces.)
+- Remind them to inspect assigned Tasks at the start of each session.
+
+---
+
+${capabilitySection}
+
+## Optional: walk through a small task end-to-end
+
+If they want to practice before touching real work, offer to pick a tiny
+P3 task or a typo fix and run the full cycle together: define → approve →
+execute → verify → close.
+
+---
+
+## Completion
+
+When they feel oriented (or after you've covered the four topics with
+reasonable back-and-forth), guide them to run:
+
+\`\`\`bash
+pactile task archive 00-join-${slug} --check
+pactile task archive 00-join-${slug}
+\`\`\`
+
+---
+
+## Suggested opening line
+
+"Welcome! Your \`pactile init\` set me up to onboard you to this project. I
+can walk you through the workflow, show you the runtime mechanics under the
+hood, summarize the team's spec, or jump to what you're already curious about
+— which would you prefer?"
 `;
 }
 /**
@@ -653,24 +503,24 @@ hood, summarize the team's spec, or jump to what you're already curious about
  * project. Task name is slugified to be filesystem-safe for arbitrary
  * developer names (spaces, Unicode, punctuation).
  */
-function createJoinerOnboardingTask(cwd, developer, pythonCmd) {
+function createJoinerOnboardingTask(cwd, developer) {
     const slug = slugifyDeveloperName(developer);
     const taskName = `00-join-${slug}`;
     const taskJson = getJoinerTaskJson(developer, taskName);
-    const prdContent = getJoinerPrdContent(developer, pythonCmd, loadProjectCapabilities(cwd));
+    const prdContent = getJoinerPrdContent(developer, loadProjectCapabilities(cwd));
     return writeTaskSkeleton(cwd, taskName, taskJson, prdContent);
 }
 /**
  * Handle re-init when .pactile/ already exists.
  * Returns true if handled (caller should return), false if user chose full re-init.
  */
-async function handleReinit(cwd, options, developerName, pythonCmd) {
+async function handleReinit(cwd, options, developerName) {
     const TOOLS = getPactileInitToolChoices();
     const installState = new InstallStateStore(cwd).read();
     const configuredPlatforms = new Set((installState?.state.installedAdapters ?? [])
         .filter((adapter) => adapter.status === "active")
         .map((adapter) => adapter.id.replace(/^adapter\./, ""))
-        .filter((platform) => platform === "cursor" || platform === "codex"));
+        .filter((platform) => platform === "codex"));
     const configuredNames = [...configuredPlatforms]
         .map((id) => TOOLS.find((choice) => choice.platformId === id)?.name ?? id)
         .join(", ");
@@ -683,7 +533,7 @@ async function handleReinit(cwd, options, developerName, pythonCmd) {
     if (!doAddPlatforms && !doAddDeveloper) {
         if (options.yes) {
             console.log(chalk.gray(`Already initialized with: ${configuredNames}`));
-            console.log(chalk.gray("Use platform flags (e.g., --cursor) or -u <name> to add platforms/developer."));
+            console.log(chalk.gray("Use --codex or -u <name> to add a platform/developer."));
             return true;
         }
         console.log(chalk.gray(`\n   Already initialized with: ${configuredNames}\n`));
@@ -769,26 +619,21 @@ async function handleReinit(cwd, options, developerName, pythonCmd) {
             }
         }
         // Capture pre-init state: if .developer did not exist before we ran
-        // init_developer.py, this checkout had no identity → treat as a new
+        // the Node identity writer, this checkout had no identity → treat as a new
         // joiner onboarding onto an existing Pactile project.
         const hadDeveloperFileBefore = fs.existsSync(path.join(cwd, DIR_NAMES.WORKFLOW, FILE_NAMES.DEVELOPER));
         try {
-            const scriptPath = path.join(cwd, PATHS.SCRIPTS, "init_developer.py");
-            execSync(`${pythonCmd} "${scriptPath}" "${devName}"`, {
-                cwd,
-                stdio: "pipe",
-            });
+            initializeDeveloper(cwd, devName);
             console.log(chalk.green(`✓ Developer "${devName}" initialized`));
         }
-        catch {
-            console.log(chalk.yellow("⚠ Could not initialize developer. Run manually:"));
-            console.log(chalk.gray(`  ${pythonCmd} .pactile/scripts/init_developer.py ${devName}`));
+        catch (err) {
+            console.log(chalk.yellow(`⚠ Could not initialize developer: ${err instanceof Error ? err.message : String(err)}`));
         }
         // Create joiner onboarding task for fresh checkouts (no prior .developer).
         // Runs outside the init_developer try/catch so failures surface as warnings.
         if (!hadDeveloperFileBefore) {
             try {
-                if (!createJoinerOnboardingTask(cwd, devName, pythonCmd)) {
+                if (!createJoinerOnboardingTask(cwd, devName)) {
                     console.warn(chalk.yellow("⚠ Failed to create joiner onboarding task"));
                 }
             }
@@ -800,19 +645,7 @@ async function handleReinit(cwd, options, developerName, pythonCmd) {
     return true;
 }
 function getPactileInitToolChoices() {
-    return [
-        ...getInitToolChoices().map((choice) => ({
-            ...choice,
-            key: choice.key,
-            platformId: choice.platformId,
-        })),
-        {
-            key: "codex",
-            name: "Codex (ChatGPT desktop app)",
-            defaultChecked: true,
-            platformId: "codex",
-        },
-    ];
+    return getInitToolChoices();
 }
 /**
  * Write monorepo package configuration to config.yaml (non-destructive patch).
@@ -897,7 +730,7 @@ export async function init(options) {
     // Generate ASCII art banner dynamically using FIGlet "Rebel" font
     const banner = figlet.textSync("Pactile", { font: "Rebel" });
     console.log(chalk.cyan(`\n${banner.trimEnd()}`));
-    console.log(chalk.gray("\n   Cross-platform AI workflow framework for Cursor & Codex\n"));
+    console.log(chalk.gray("\n   Governed AI workflow for Codex\n"));
     // Set up proxy before any network calls
     const proxyUrl = setupProxy();
     if (proxyUrl) {
@@ -940,7 +773,6 @@ export async function init(options) {
     if (developerName) {
         console.log(chalk.blue("👤 Developer:"), chalk.gray(developerName));
     }
-    const { command: pythonCmd } = resolveSupportedPython();
     // ==========================================================================
     // Re-init fast path: skip full flow when .pactile/ already exists.
     // ==========================================================================
@@ -955,7 +787,7 @@ export async function init(options) {
         !options.force &&
         !options.skipExisting &&
         !tasksEmptyEarly) {
-        const reinitDone = await handleReinit(cwd, options, developerName, pythonCmd);
+        const reinitDone = await handleReinit(cwd, options, developerName);
         if (reinitDone)
             return;
         // reinitDone === false means user chose "full re-initialize" → fall through
@@ -1132,7 +964,7 @@ export async function init(options) {
         tools = explicitTools;
     }
     else if (options.yes) {
-        // No explicit tools + -y: default to Cursor and Codex
+        // No explicit tools + -y: use the active host default.
         tools = TOOLS.filter((t) => t.defaultChecked).map((t) => t.key);
     }
     else {
@@ -1595,17 +1427,14 @@ export async function init(options) {
         // migration backup or prompt for a legacy transition that never existed.
         writeWaveCConfirmed(cwd);
     }
-    // Initialize developer identity (silent - no output)
+    // Initialize developer identity with Node (silent - no output).
     if (developerName) {
         try {
-            const scriptPath = path.join(cwd, PATHS.SCRIPTS, "init_developer.py");
-            execSync(`${pythonCmd} "${scriptPath}" "${developerName}"`, {
-                cwd,
-                stdio: "pipe", // Silent
-            });
+            if (!readDeveloper(cwd))
+                initializeDeveloper(cwd, developerName);
         }
         catch {
-            // Silent failure - user can run init_developer.py manually
+            // Preserve init's best-effort identity creation boundary.
         }
         // Three-branch dispatch using flags captured at init() start (before
         // createWorkflowStructure/init_developer ran, so they reflect the disk
@@ -1625,14 +1454,14 @@ export async function init(options) {
         const tasksDir = path.join(cwd, PATHS.TASKS);
         const tasksEmpty = !fs.existsSync(tasksDir) || fs.readdirSync(tasksDir).length === 0;
         if ((isFirstInit && !importingCstl) || tasksEmpty) {
-            const bootstrapCreated = createBootstrapTask(cwd, developerName, pythonCmd, projectType, selectedCapabilities, monorepoPackages);
+            const bootstrapCreated = createBootstrapTask(cwd, developerName, projectType, selectedCapabilities, monorepoPackages);
             if (bootstrapCreated) {
                 console.log(chalk.gray(`Next: complete ${BOOTSTRAP_TASK_NAME} to verify selected capabilities and fill the project spec.`));
             }
         }
         else if (!hadDeveloperFileAtStart) {
             try {
-                if (!createJoinerOnboardingTask(cwd, developerName, pythonCmd)) {
+                if (!createJoinerOnboardingTask(cwd, developerName)) {
                     console.warn(chalk.yellow("⚠ Failed to create joiner onboarding task"));
                 }
             }