Packwright 0.3.1

Packwright 0.3.1

Packwright 0.3.1 is a focused migration-safety maintenance release. It makes
destination runtime capability gaps explicit, keeps human-readable receipts
safe when a gap represents behavior rather than a file, and fixes false
readiness failures for live memory.

Install

python -m pip install packwright==0.3.1

Explicit destination capability gaps

Migration planning now inspects unavailable canonical automations for every
destination adapter. Cursor's unavailable prompt-time todo context is reported
with the same honesty as Pi's lifecycle gaps instead of being silently omitted.

When a migration has one of these gaps:

• dry-run remains successful and writes nothing;
• the receipt names the affected automation and behavior;
• interactive apply asks for explicit acceptance; and
• non-interactive apply requires --accept-degraded in addition to --yes.

Existing scripts that migrate to Cursor with --yes may now stop with exit
status 2 until the operator reviews the receipt and deliberately adds
--accept-degraded. This is an intentional safety correction.

Safe human-readable receipts

Runtime capability gaps do not always correspond to a destination path. The
human receipt now renders those items as labels such as:

automation:user-prompt-current-todos (user_prompt -> add_context)

Dry-run, rejected apply, and accepted apply no longer crash while formatting
these pathless records.

Readiness and projection corrections

• Populated pinned, recent-activity, and todo memory files count as usable live
  state, so a migrated target can retain a clean installed score.
• Runtime-name checks use token boundaries; words such as Pinpoint and
  Picture no longer create false Pi projection failures.
• Emotion Engine-to-Pi receipts state that Pi Core has no Emotion Engine runtime
  projection. Portable state may remain as inert data, but no runtime is
  claimed.
• Pi documentation uses the exact generated skill and reference paths and
  explains that /trust saves a future decision without reloading the current
  session.

Verification

The release is covered by 120 source tests, all 12 directed adapter migrations,
legacy Emotion Engine retirement guards, dry-run provenance preservation, real
terminal dry-run/rejection/accepted-apply checks for Cursor and Pi, and the full
package release gate across Python 3.9 through 3.14.

Compatibility

Packwright 0.3.1 remains local-only and requires Python 3.9 or newer. It does not
add an executable Pi extension or a Pi-native Emotion Engine runtime. Existing
0.3.0 sources and installed targets remain diagnosable, migratable, and
reconcilable.

Packwright 0.3.0 — Pi Core support

Packwright 0.3.0 adds first-class Pi Core support and makes its verification language more honest. One canonical agent source can now build native targets for Pi, Codex, Claude Code, and Cursor, with all 12 directed migration paths covered by the release gate.

Install

python -m pip install packwright==0.3.0

Pi Core

Build and install a native Pi target:

packwright init --template code --name Nova -o work/nova
packwright build work/nova --adapter pi -o pack/nova-pi
packwright install pack/nova-pi --adapter pi --target project/nova-pi

The Pi adapter emits:

• AGENTS.md for project context;
• .agents/skills/<name>/SKILL.md for project Agent Skills;
• .pi/<name>/references/ for adapter-scoped references; and
• explicit project-trust activation guidance for /trust or pi --approve.

Packwright does not generate executable Pi extensions. Canonical session_start and user_prompt automations are recorded as capability gaps, and migration to Pi requires --accept-degraded after review. Pi Core also has no built-in MCP surface, so the optional Emotion Engine runtime cannot be activated there; portable state may still be carried as inert data.

Honest readiness

score continues to provide the stable structural passed result, but now includes a machine-readable packwright-readiness/v1 block. A structural 100.0 explicitly leaves portable state, runtime activation, environment bindings, and workflow acceptance as not_evaluated.

doctor keeps its backward-compatible ok result for managed projection integrity and adds target readiness evidence. It reports:

• unverified Pi project trust;
• unavailable or review-pending canonical automations;
• pending adoption-review items; and
• the readiness layers that Packwright cannot yet evaluate.

This is intentionally a minimal false-green fix: existing automation can keep using passed and ok, while people and newer integrations can stop treating structural integrity as proof of live workflow readiness.

Other hardening

• install --dry-run returns a complete no-write change plan.
• Install provenance is persisted under .packwright/install-provenance.json and exposed by doctor.
• Legacy Emotion Engine state can be explicitly retired as a verified backup.
• Reconcile now converges against the same final projection used for scoring, installation, and artifact locking.

Compatibility

Packwright 0.3.0 remains local-only and requires Python 3.9 or newer. Existing 0.2.0 canonical sources and installed targets remain diagnosable, migratable, and reconcilable. Installing the Python package alone does not modify a target.

Release Packwright 0.2.0

Packwright 0.2.0 makes the editable save-context source authoritative across Codex, Claude Code, and Cursor.

What changed

• The body at skills[].path is now the only semantic source for the required save-context skill. Adapters generate only the runtime destination path and front matter.
• New English and Chinese scaffolds include a Memory Tracks section generated from the same structured track data as memory-policy.yaml.
• Customized and older sources do not need a Memory Tracks heading. The checker still requires a Procedure section, memory/session-index.md, canonical-owner guidance, and runtime-neutral wording.
• Save-context is mandatory and cannot be capability-gated.
• Projection-neutrality failures now identify the canonical source path and the runtime-specific token that must be removed.

Upgrade and reconcile behavior

Installing 0.2.0 does not modify an installed target. On the first reconcile from a canonical work directory, dry-run reports the save-context projection as a normal managed update. Apply replaces that managed projection with the work-directory source body, refreshes the embedded source snapshot and lock, and preserves portable instance state. --force is not required.

Users who customized the work-directory source will see that content projected for the first time. Users who kept the default source may see save-context wording change from the old adapter-owned template to the scaffolded source.

The canonical edit location is the work directory, such as work/<character>/skills/save-context/SKILL.md. Changes made only in an installed runtime projection or in .packwright/source are not canonical and are overwritten by a later reconcile.

Before the first reconcile, doctor continues to validate the target against its existing lock. If the old projection is manually changed during this window, doctor --fix may refuse repair because the 0.2.0 compiler output no longer matches the old lock. Reconcile first, then rerun doctor.

Verification

• 101/101 tests passed.
• Full source, package, three-adapter install, doctor, score, and migration release gate passed.
• Python 3.9–3.14 CI and package checks passed.

Install

python -m pip install packwright==0.2.0

Packwright 0.1.2

Packwright 0.1.2 closes the local runtime-automation loop across Codex, Claude
Code, and Cursor while keeping canonical intent separate from task handoff and
portable instance state.

Canonical local automations

• Runtime-neutral mechanism 0.8 declares bounded session_start and
  user_prompt context automations.
• Declarative producers cover local memory views, current date/time facts, and
  target relocation checks. They do not trigger from prompt keywords and do not
  run arbitrary user commands.
• Legacy mechanism 0.5, 0.6, and 0.7 sources normalize in memory to the 0.8
  contract without rewriting editable source files.

Native runtime projection

• Claude Code receives project-local SessionStart and UserPromptSubmit
  command hooks.
• Codex receives project-local SessionStart and UserPromptSubmit hooks and
  records project trust/hook review as an activation step.
• Cursor receives sessionStart context. Its beforeSubmitPrompt surface
  cannot add model context, so Packwright records
  unavailable_missing_effect instead of claiming compatibility.
• Generated Python runners enforce UTF-8 byte budgets and read only local
  project files. Cloud agents remain outside this release scope.

Reconcile and ownership

• packwright reconcile previews and applies same-instance mechanism upgrades
  from canonical intent rather than reverse-compiling another runtime's hooks.
• Plans and receipts include installed/desired spec hashes, optional Git
  provenance, managed projection changes, preserved instance state, manual
  merges, capability gaps, and pending activation steps.
• Runtime JSON uses entry-level Packwright ownership and fragment hashes.
  Install, reconcile, and doctor preserve unrelated user settings and hooks.
• Existing installed Emotion Engine sidecars and live portable state survive
  reconcile.

Adoption and migration safety

• Adopt classifies existing local hooks as automation candidates and can create
  evidence-only canonicalization drafts. It never reverse-compiles behavior or
  edits mechanism.yaml automatically.
• Migration inventories unmanaged hook configuration and supporting assets,
  reports destination behavior gaps, and requires separate
  --accept-degraded confirmation before non-interactive apply.
• Handoff remains task continuity only. It does not transfer hooks, skills,
  schemas, or memory structure.

Install

python -m pip install packwright==0.1.2
packwright --version

Then follow the README quickstart, use the
paste-ready coding-agent prompt, or read the
local runtime automation contract.

Verification

The local release gate passes 96 tests, Python compilation, zero-network audit,
public-tree history audit, generated runner execution for all three adapters,
Claude Code/Codex prompt-refresh execution, Cursor capability degradation,
state-preserving reconcile, and evidence-only adoption drafts.

Packwright 0.1.2 remains local-only. It does not add cloud hook execution,
scheduled tasks, session_end, pre_compact, or arbitrary custom commands.

Packwright 0.1.1

Packwright 0.1.1

Packwright 0.1.1 hardens portability across Codex, Claude Code, and Cursor while
keeping the compiler deterministic, local, and inspectable.

Runtime-neutral foundations

• Adapter names, native paths, guidance formats, capabilities, and lifecycle
  behavior now live in a central registry instead of leaking through canonical
  character and skill specifications.
• Install infers the adapter from the pack manifest; --adapter remains an
  optional assertion.
• Existing 0.1.0 mechanism and installed-target metadata is normalized into the
  current runtime-neutral contract for diagnosis, scoring, and migration.

Emotion Engine v1.0.0

• The optional Emotion Engine integration is now adapter-neutral and available
  to Codex, Claude Code, and Cursor.
• Each adapter receives its native guidance and project MCP configuration while
  sharing the same pinned v1.0.0 runtime and canonical
  .emotion-engine/state.json state file.
• Legacy state files are carried byte-for-byte when unambiguous. Conflicting
  legacy states stop before target writes, and refresh, doctor, and force flows
  do not reset live state.

Skills and locale

• Every semantic skills: entry projects through the adapter registry.
  Capability requirements can degrade explicitly without putting runtime names
  in the canonical mechanism.
• Compiler-owned boilerplate supports deterministic en and zh-CN output.
  Missing or unsupported locales fall back to English, while user-authored
  identity, memory, and skill prose remains unchanged.
• Checker rules use resolved locale and semantic section contracts instead of
  relying on English-only headings.

Safer shorter workflows

• packwright new can create source, build a checked pack, and install a fresh
  target in one command while preserving all three directories. It refuses
  existing or overlapping paths.
• Preset use through new requires explicit --accept-preset after review.
• Reviewed adoption queues now have a dry-run-first apply phase with per-item
  SHA-256 checks. Safe workspace/skill copies and source registrations can be
  applied; memory merge and knowledge promotion remain manual.
• Agent-operation documentation now identifies which safeguards are enforced
  mechanically and which depend on the coding agent following the prompt.
• Installed handoff wrappers use the scoped PACKWRIGHT_PYTHON override rather
  than inheriting a build environment's generic PYTHON path.

Install

python -m pip install packwright==0.1.1
packwright --version

Then follow the README quickstart or use the
paste-ready coding-agent prompt.

Verification

The release gate runs the complete source suite across Python 3.9 through 3.14,
zero-network and public-tree audits, wheel and sdist validation, clean package
installs, all three adapter workflows, and migration integrity checks.

As before, a 100.0 score proves the structural contract passes; it is not a
guarantee of runtime behavior. Packwright itself makes no network requests and
sends no telemetry.

Packwright 0.1.0

Packwright 0.1.0 is the first stable release of the local-first compiler for portable agent packs across Codex, Claude Code, and Cursor.

Highlights

• Create your own agent first. Use packwright draft-character to turn a conversation into a confirmed intake, or packwright adopt to inventory an existing local agent.
• Three nameless presets. code, work, and companion provide editable starting roles; the user always chooses the character name.
• Native portable packs. Build, install, diagnose, score, and migrate one editable source across Codex, Claude Code, and Cursor.
• Reviewable migration. Preview generated, carried, rewritten, and excluded paths before any destination is written.
• Safer local state. Path traversal and symlink escapes are rejected, install --force preserves portable user state, and doctor repairs only reproducible managed drift.
• Zero-network guardrail. Expanded auditing covers Python, embedded generated source, CSP, JavaScript, scripts, examples, and templates.
• Optional Emotion Engine. The Codex sidecar remains explicitly installed and keeps live state separate from durable memory.

Install

python -m pip install packwright==0.1.0
packwright --version

Verification

• 69 source and sdist tests passed
• zero-network and public-tree audits passed
• wheel and sdist passed package metadata checks and clean-environment installs
• Codex, Claude Code, and Cursor build/install/doctor/score flows passed at 100.0
• Codex-to-Cursor migration verified 27 integrity hashes

See the README and full release notes.

Packwright 0.1.0rc1

Packwright 0.1.0rc1

This release candidate is for local and external installation testing before the stable 0.1.0 release.

Highlights:

• Build plain-file agent packs for Codex, Claude Code, and Cursor.
• Preview migrations before writing, then apply the reviewed plan with --yes.
• Inspect generated, carried, rewritten, and excluded paths with hash verification.
• Run doctor and score against self-contained installed targets.

Known limits:

• A score of 100.0 means the pack satisfies Packwright's public structural rules; it is not a guarantee of runtime behavior.
• Real interactive smoke tests in all three coding runtimes remain an external release gate.
• Packwright itself makes no network requests and sends no telemetry. Your files stay under your control; your coding runtime's own data policy still applies.