pi-career 0.1.0 → 0.3.0

package/docs/native-dependency-inventory.md

@@ -2,17 +2,17 @@
 
 ## Status and scope
 
-This is reproducible dependency evidence for the two native `career` binaries tracked by pi-career. It is **not legal advice**, a legal-compliance conclusion, an SPDX/CycloneDX SBOM, or release approval. A human license review remains mandatory under [`releasing.md`](releasing.md).
+This is historical reproducible dependency evidence for the two native `career` binaries packaged by pi-career `v0.1.0` and its pre-external-resolver development candidate. Pi-career `v0.2.0` and later track and package no native binary; native distribution evidence belongs to `@revazi/career`. This document is **not legal advice**, a legal-compliance conclusion, an SPDX/CycloneDX SBOM, or release approval.
 
 The inventory is pinned to:
 
-- Career Core commit [`a3cdb4c6d7f966397e93ea4664071975bca7228c`](https://github.com/revazi/career-core/tree/a3cdb4c6d7f966397e93ea4664071975bca7228c)
+- Career Core commit [`f6d17835de4817e28ce84e8e5734ff592687dfcc`](https://github.com/revazi/career-core/tree/f6d17835de4817e28ce84e8e5734ff592687dfcc)
 - Cargo.lock SHA-256 `18d188cfea79128d4024dabe2e21f57e5d2098d32ffac8c4ef01243f49abb609`
 - package `career-cli 0.1.0`
 - build edges `normal,build`, excluding development dependencies
 - targets `aarch64-apple-darwin` and `x86_64-unknown-linux-gnu`
 
-The per-target provenance records show the corresponding locked release builds:
+The historical per-target provenance records showed the corresponding locked release builds:
 
 ```text
 cargo build --release --locked -p career-cli --target aarch64-apple-darwin
@@ -21,7 +21,7 @@ cargo build --release --locked -p career-cli --target x86_64-unknown-linux-gnu
 
 ## Derivation
 
-The Career Core checkout was treated as read-only. The exact commit was exported to a temporary directory outside both repositories; the temporary export was removed after these offline commands:
+The original dependency graph was derived from a read-only Career Core export using the offline commands below. For Phase 8 commit `f6d1783`, the lockfile remains byte-identical at the pinned SHA-256 and the manifest diff adds ownership/publication metadata but no normal/build dependency; both new per-target provenance records retain the same locked Rust 1.97.1 release-build boundary.
 
 ```bash
 cargo metadata --locked --offline \
@@ -47,8 +47,8 @@ For crates.io packages, “Source” identifies the immutable name/version regis
 | `anstyle` | `1.0.14` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/anstyle/1.0.14) | `940b3a0ca603d1eade50a4846a2afffd5ef57a9feac2c0e2ec2e14f9ead76000` |
 | `anstyle-parse` | `1.0.0` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/anstyle-parse/1.0.0) | `52ce7f38b242319f7cabaa6813055467063ecdc9d355bbb4ce0c68908cd8130e` |
 | `anstyle-query` | `1.1.5` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/anstyle-query/1.1.5) | `40c48f72fd53cd289104fc64099abca73db4166ad86ea0b4341abe65af83dadc` |
-| `career-cli` | `0.1.0` | `MIT OR Apache-2.0` | [Core workspace](https://github.com/revazi/career-core/tree/a3cdb4c6d7f966397e93ea4664071975bca7228c/crates/career-cli) | commit-bound |
-| `career-core` | `0.1.0` | `MIT OR Apache-2.0` | [Core workspace](https://github.com/revazi/career-core/tree/a3cdb4c6d7f966397e93ea4664071975bca7228c) | commit-bound |
+| `career-cli` | `0.1.0` | `MIT OR Apache-2.0` | [Core workspace](https://github.com/revazi/career-core/tree/f6d17835de4817e28ce84e8e5734ff592687dfcc/crates/career-cli) | commit-bound |
+| `career-core` | `0.1.0` | `MIT OR Apache-2.0` | [Core workspace](https://github.com/revazi/career-core/tree/f6d17835de4817e28ce84e8e5734ff592687dfcc) | commit-bound |
 | `clap` | `4.6.4` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/clap/4.6.4) | `d91e0c145792ef73a6ad36d27c75ac09f1832222a3c209689d90f534685ee5b7` |
 | `clap_builder` | `4.6.2` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/clap_builder/4.6.2) | `f09628afdcc538b57f3c6341e9c8e9970f18e4a481690a64974d7023bd33548b` |
 | `clap_derive` | `4.6.4` | `MIT OR Apache-2.0` | [crates.io](https://crates.io/crates/clap_derive/4.6.4) | `d012d2b9d65aca7f18f4d9878a045bc17899bba951561ba5ec3c2ba1eed9a061` |

package/docs/product-flow.md

@@ -1,8 +1,10 @@
 # Product flow roadmap
 
-## Current phase: deterministic tools and slash-command MVP
+The cross-repository migration plan and measured findings are recorded in [`career-run-roadmap.md`](career-run-roadmap.md). Career Core Phase 8, the first managed `career_run` implementation, and the threat-reviewed package-owned Markdown/text save workflow in [`variant-save-workflow.md`](variant-save-workflow.md) are complete. Synthetic PDF compatibility covers reviewed Chromium-generated tagged/untagged and ReportLab-generated two-page documents, embedded-font and multi-column layouts, and fail-closed text-unavailable cases. The Git-history/tree/hash-bound token-optimization study is complete: its frozen before/after evidence includes Pi Skill discovery and matching-task full-Skill context and records a 15.98% aggregate workflow reduction with no workflow regression. Full application-workspace persistence and further PDF extraction expansion remain later phases.
 
-This package preserves the three stable native tools:
+## Current phase: managed agent tool and deterministic slash commands
+
+The normal active model surface is one compact `career_run` tool. The exact raw compatibility tools remain registered but inactive until `/career-tools raw` explicitly enables them:
 
 - `career_core_discover`
 - `career_core_resume`
@@ -10,38 +12,57 @@ This package preserves the three stable native tools:
 
 It also registers:
 
-- `/career-setup` for library and privacy onboarding—not external CLI installation
-- `/career-library` for explicitly configured Markdown/text resume roots
+- `/career-setup` for library/privacy onboarding and a suggestion-only preferred variation directory—not external CLI installation
+- `/career-library` for explicitly configured searchable PDF, Markdown, and text resume roots, with actionable extraction notices
+- `/career-application` for session-scoped company/role identity and vacancy/result isolation
 - `/career-vacancy` for bounded vacancy input after session-persistence consent
 - `/career-match` for deterministic multi-resume matching and conservative ranking
 - `/career-analyze` for deterministic single-resume readiness detail
+- `/career-workbench` for a bounded, guided, visibly reviewable rebuild handoff to the user's normal Pi editor
+- `/career-review` for TUI-only, bounded inspection and explicit selection of current non-PDF retained variant changes
+- `/career-save` for user-only TUI/RPC exact preview, confirmation, and no-clobber local saving of one current Markdown/text materialization
+- `/career-tools` to switch between the managed-only and advanced raw model-tool surfaces
 
-On supported targets all eight routes invoke the package-owned deterministic Career Core runtime. Slash commands call the shared process helper directly and do not use a provider/model or an LLM-facing tool.
+`career_run`, the raw compatibility tools, `/career-vacancy`, `/career-match`, and `/career-analyze` invoke the compatible Career Core route selected by the external resolver on supported macOS/Linux systems. Package metadata rejects other systems, and direct local/Git extension initialization registers no command/tool and fails with `unsupported_platform` before route work or private stdin. Managed compatibility is validated before private input, and the reviewed exact package may be acquired only after local routes fail unless `PI_OFFLINE=1`. `career_run` validates Phase 8 operation/schema contracts internally, resolves current originals/vacancy through ephemeral handles, keeps complete results in bounded process memory, and exposes compact detail hydration without nested `input_json`. Setup/library scanning remains local. `/career-application` manages consented session state only. `/career-workbench` does not invoke Core or a provider/model itself: it prepares an ordinary editor message containing one original resume and, only for tailoring, the current vacancy. Guided modes cover complete score explanation, reviewed improvement suggestions, a question-led factual interview before reviewed replacements, direct reviewed exact replacements, and vacancy-specific variant review. The user must review and submit that message separately through Pi. `/career-review` also invokes neither Core nor a provider: it reads one current in-memory non-PDF variant review, requires warnings/discards acknowledgment and exact per-change inspection before inclusion, then prepares a later editor message containing only the unchanged review handle and selected canonical IDs.
 
 Binding boundaries:
 
-- no provider/model calls in deterministic commands
-- agent-directory-relative non-sensitive config only
-- no resume or vacancy text in global config
+- no package-initiated provider/model calls or automatic submission; the workbench stops at a reviewable editor prompt, and only the user's later ordinary Pi submission may contact the selected provider; exact-package acquisition before private stdin is the sole network-capable adapter-runtime behavior
+- agent-directory-relative non-sensitive config only; it may contain canonical library roots and one bounded absolute preferred variation-directory suggestion
+- no resume or vacancy text in global config; a variation-directory preference is destination guidance, not write approval
 - session entries only after explicit persistence consent; entries persist to JSONL even when excluded from model context
+- one company/role per Pi session; application IDs scope vacancy/result state and `/new` prevents prior company prompts from remaining in the next application conversation
 - original resumes only for deterministic analyze/match
 - assisted variants remain labeled and excluded from authoritative reranking
 - stable path/id tie-breaking; any close-cluster label is a UI heuristic, not a Core result
 - cancellation aborts the active child and stops remaining batch work
-- no full-result export unless a separate bounded local-file workflow is designed and tested
+- complete slash-command Core results remain transiently inspectable through a read-only pager; managed full results/exact review inputs remain only in a 16-entry/64-MiB ephemeral registry, and no full JSON is added to session state or written to a file
+- searchable PDF text extraction is local and isolated with fixed byte/page/time/memory/result ceilings; OCR and document rewriting remain out of scope
+- workbench prompts keep originals immutable, omit absolute source paths, treat document text as untrusted data, rerun complete deterministic baselines after submission, and require Career Core review of external suggestions, replacements, and variant changes
+- workbench prompts may include a privacy-reduced preferred variation-directory display path from setup; the selected agent recommends it first only after a separate user request and receives no automatic write authority
+- review proposals use verbatim source targets and in-range evidence, prefer single-line targets, make one review attempt, and surface discard codes instead of model-led repair/retry loops
+- `career_run variant-review` terminates its turn; the TUI selector defaults every retained change to excluded, pages exact before/after/evidence locally, then pages selected changes together as compact labeled exact records, permits direct final-stage reopening of each record, and requires a separate prepare-or-back decision
+- review selection is process-memory-only: only the final prepare choice puts the ephemeral review handle and selected canonical IDs in the editor; pi-career appends no selection entry and performs no Core call
+- PDF review changes remain manual guidance; `/career-review` and `career_run materialize` reject PDF review handles because extracted text cannot preserve the styled document
+- raw tool JSON remains authoritative; managed projections refer to complete authoritative in-memory results by handle, while prose hydrates only requested evidence and retained items
+- PDF workbench output is suggestion-only because extracted text cannot expose or preserve visual layout; Markdown/text prompts require existing structure and unchanged wording to remain intact
+- no full-result file export; `/career-save` persists only exact approved assisted document bytes and bounded marker/sidecar metadata
+
+The approved workflow specification fixes command behavior, persistence format, non-TUI behavior, bounded UI, and cancellation ownership. Print/JSON modes fail closed except for the pure `/career-vacancy clear` state action. Company/role isolation and future opt-in artifact persistence follow the separate [`application-workspaces.md`](application-workspaces.md) contract.
+
+## Assisted handoff and later materialization
 
-The approved workflow specification fixes command behavior, persistence format, non-TUI behavior, bounded UI, and cancellation ownership. Print/JSON modes fail closed except for the pure `/career-vacancy clear` state action.
+The current workbench prepares private context in Pi's editor only. It does not call a model, hide the source payload, or write a document. Submitting is the user's separate provider action. The prompt directs the selected Pi agent to start with `career_run context`, use internal exact Phase 8 contract discovery, rerun and preserve complete deterministic baselines behind ephemeral handles, and pass external suggestions, replacements, or variant changes through the corresponding Career Core review before presenting them. The question-led rewrite mode reviews first, asks one bounded batch of user-verifiable factual questions, and waits for a later turn before drafting or reviewing exact replacements.
 
-## Later phase: assisted workflows
+For a non-PDF vacancy-specific variant, the first assisted turn stops mechanically after review. In TUI, the user can run `/career-review <review-handle>` to page all warnings/discards and exact retained changes. Every change starts excluded and can be included only from its exact detail view. Continuing pages all selected exact records together with compact labels and permits direct read-only reopening of each one; a separate final choice either returns to review or prepares—but never submits—the later user message with exactly the selected Core IDs and unchanged handle. Only after the user reviews and submits that message may deterministic materialization run. The result remains assisted/non-authoritative and cannot enter authoritative analysis or matching. PDF workbenches stop after reviewed targeted changes for manual application; PDF handles are rejected by selection and materialization and never turn extracted text into a styled resume.
 
-Model-assisted tailoring or suggestion review is intentionally deferred. A future phase may use the currently selected Pi model only after separate provider consent, validate one bounded schema-driven proposal, pass it through Career Core review/materialization, and save a new immutable assisted file. It must not add provider fallback, automatic repair/retry, overwrite originals, auto-apply changes, or feed assisted output back into authoritative analysis/matching.
+Automatic variant saving remains prohibited. Setup records or derives only a preferred destination suggestion and creates no directory or file. After a successful non-PDF materialization, the user may separately run `/career-save <variant-handle>`: it derives an eligible direct-child managed destination, shows the complete exact plan, requires unchanged preview plus separate confirmation, performs no-clobber private writes, and succeeds only after fail-closed rescanning excludes the artifact from originals. It does not add provider fallback, automatic repair/retry, original overwrite, auto-application, or authoritative reranking.
 
 ## Non-goals in this phase
 
-- provider/model-assisted commands or full-screen UI
-- PDF/DOCX/OCR/URL ingestion
-- model/provider integration
+- package-initiated provider/model clients, credentials, automatic prompt submission, or full-screen UI
+- DOCX/OCR/URL ingestion; image-only PDFs require external OCR or export
 - source-document or full-Core-result persistence outside the approved config/custom-entry workflow
 - source document mutation
-- publication, release downloads, signing, or notarization
-- expanded runtime platform claims beyond `darwin-arm64` and `linux-x64-gnu`
+- career-document publication/export, release-asset downloads, signing, or notarization
+- package-owned native binaries or platform claims beyond pi-career's six reviewed macOS/Linux targets; the launcher's additional upstream manifest entries are contract metadata, not support

package/docs/releasing.md

@@ -1,79 +1,113 @@
 # Release process
 
-This document records the bounded `v0.1.0` release process and evidence requirements.
+This document defines the bounded trusted-publishing process for the next explicitly authorized pi-career release and records the historical `v0.1.0` and `v0.2.0` outcomes. In the instructions below, `<version>` is the exact package version without `v`, `<tag>` is `v<version>`, and `<sha>` is the full frozen candidate commit.
 
-## Approved channel boundary
+## Release boundary
 
-After every gate below is closed, the authorized channels are:
+One coordinated release may create exactly:
 
-1. one public `pi-career@0.1.0` npm package;
-2. one annotated, unsigned `v0.1.0` Git tag pointing to the exact published commit; and
-3. one GitHub Release containing notes derived from the finalized `CHANGELOG.md` entry.
+1. one public `pi-career@<version>` npm package on `https://registry.npmjs.org/`;
+2. one annotated, unsigned `<tag>` Git tag pointing to the exact published commit; and
+3. one GitHub Release for that tag with notes derived from the finalized [`CHANGELOG.md`](../CHANGELOG.md) entry.
 
-The npm package contains the strict allowlisted artifact tested by `npm run check:package`, including both unsigned native binaries. The project will not publish to crates.io, attach the npm tarball or native binary as a custom GitHub Release asset, add lifecycle/publication scripts, or claim signing/notarization. GitHub automatically generated source archives contain the complete tracked tree and are not substitutes for the tested npm artifact.
+The npm package must be the native-free allowlisted artifact verified by `npm run check:package`. It contains the Pi extension, generated PDF worker, Agent Skill, and documentation. It must contain no `runtime/`, native executable, `node_modules`, Pi peer package contents, production dependency tree, lifecycle download/build hook, or publication script.
 
-The exact npm version and reviewed full commit SHA are the canonical installation and audit coordinates. The GitHub Release notes must state that SHA and the npm package's registry integrity. A tag is a discovery label, not a substitute for immutable commit review, and README Git installation instructions must continue to use a full SHA.
+Career Core distribution remains external. The candidate pins exact [`@revazi/career@0.2.0`](https://www.npmjs.com/package/@revazi/career/v/0.2.0); its reviewed launcher owns native target/libc, package metadata, provenance, file invariants, size, format, architecture, and SHA-256 verification. Pi-career supports only its six macOS/Linux targets and must not copy those algorithms or artifacts. Pi-career validates the exact ordered six-package v2 launcher manifest, declared file allowlist, and `career` bin before direct execution.
 
-There is no automated publication workflow. Release execution is manual; sole maintainer Revaz Zakalashvili explicitly authorized the coordinated `v0.1.0` npm publication, tag, and GitHub Release after the candidate gates.
+The reviewed external release is bound to Career Core commit/tag `536690632884c17336cc3c108f1bba0f254b862b`/`v0.2.0` and successful protected publication run [`31761238274`](https://github.com/revazi/career-core/actions/runs/31761238274). The launcher registry integrity is `sha512-5aksKh9S2fqPKBwlUY94XgCHjggr2Gep45zEWOMBNEfRtXvC/pYnlkI9CYrVHBFR8/gfGQog4pwV854FMzDxww==`; registry metadata reports SLSA v1 provenance for the user-facing launcher and all six lockstep launcher-owned native packages.
 
-## Blocking gates
+The sole permitted automated publication path is the tag-triggered `.github/workflows/release.yml` workflow using npm Trusted Publishing through GitHub OIDC and the protected `npm` environment. It must use no `NPM_TOKEN`, `NODE_AUTH_TOKEN`, OTP, or other long-lived publication credential. Preparation, CI success, a version bump, workflow availability, or this document does **not** authorize tag creation/push, npm publication, or a GitHub Release; release execution remains a separate explicit maintainer action. Do not publish to crates.io, attach an npm tarball/native binary as a custom GitHub Release asset, add signing/notarization claims, or add lifecycle/publication scripts.
 
-Every item in this section blocks the npm publication, tag, and GitHub Release. A skipped, unknown, or merely planned result is not a pass.
+The exact npm version and full published commit SHA are the canonical installation and audit coordinates. The GitHub Release notes must state that SHA and the npm registry integrity. A tag is a discovery label, not a substitute for immutable commit review.
 
-### 1. Freeze and review the exact candidate
+## Historical `v0.1.0` outcome
 
-- Start from synchronized public `main` and identify one full candidate SHA.
-- Ensure the candidate contains no private career content, credentials, sessions, provider output, generated local paths, or unreviewed runtime bytes.
-- Review the complete diff and confirm `package.json` remains `0.1.0`, explicitly public only at `https://registry.npmjs.org/`, peer-only at runtime, and free of lifecycle/publication scripts.
-- Confirm `src/`, `dist/index.js`, runtime manifest/provenance, package contents, supported targets, and the exact three native tools remain aligned.
-- Do not move the candidate after its local and hosted evidence is recorded. Any content change creates a new candidate and requires the gate again.
+Release execution completed on 2026-08-06:
 
-### 2. Human native-license review
+- npm: [`pi-career@0.1.0`](https://www.npmjs.com/package/pi-career/v/0.1.0)
+- commit: `967da62503bc8a97c070946f6506ea3471baeb34`
+- annotated unsigned tag: [`v0.1.0`](https://github.com/revazi/pi-career/releases/tag/v0.1.0)
+- npm integrity: `sha512-mmbDdWDyWz77f2uLzZECJT9E6w1ZRCJjYFrUnZd3ldoS6ehEa5DrCENIfavHR5xMOFi0of6AVQ35ZTxwpeDeAQ==`
+- npm shasum: `4212cea50c08c98771df267361cee28070a15765`
+- custom GitHub Release assets: none
 
-[`native-dependency-inventory.md`](native-dependency-inventory.md) records the exact 30-package normal/build Cargo graph, selected MIT texts for all 28 crates.io packages, the two Career Core workspace packages, Rust 1.97.1 Standard Library evidence, Unicode-3.0 requirement, target dynamic imports, and the Swift/UniFFI exclusion. `npm run check:native-licenses` enforces every packaged license/notice hash, inventory coordinate, target, provenance compiler version, and file boundary. This is evidence, not legal advice, an SPDX/CycloneDX SBOM, or an automated approval.
+That release bundled native Career Core artifacts. Its dependency/license/provenance evidence remains historical in [`native-dependency-inventory.md`](native-dependency-inventory.md) and [`licenses/`](licenses/). None of those native files may re-enter a future package.
 
-Before publication, a human reviewer must:
+## Historical `v0.2.0` outcome
 
-- verify the inventory against Career Core commit `a3cdb4c6d7f966397e93ea4664071975bca7228c`, Cargo.lock SHA-256 `18d188cfea79128d4024dabe2e21f57e5d2098d32ffac8c4ef01243f49abb609`, and both per-target provenance records;
-- confirm the documented MIT selections, exact grouped upstream texts/copyright notices, Rust Standard Library evidence, and Unicode License V3 payload satisfy the package-owned obligations for both native binaries;
-- confirm the host-supplied dynamic-library boundary and that excluded Fuchsia/Swift/UniFFI dependencies are not part of either distributed target; and
-- record an explicit approve/block decision without presenting the inventory as legal advice.
+Release execution completed on 2026-08-10:
 
-Independent review is preferred. When the project has only one maintainer, that sole maintainer may complete and record the review, but release notes must disclose that it was maintainer self-review rather than independent legal review. No npm publication, tag, or release may proceed while the human decision is absent or blocked. Any dependency, compiler, target, binary, provenance, or notice change invalidates the evidence and requires a fresh inventory and review.
+- npm: [`pi-career@0.2.0`](https://www.npmjs.com/package/pi-career/v/0.2.0)
+- published commit: `6db58644a6140202de2f2d661a740acd298c79b5`
+- annotated unsigned tag and GitHub Release: [`v0.2.0`](https://github.com/revazi/pi-career/releases/tag/v0.2.0)
+- npm integrity: `sha512-2V0z42oxsDHdE9a/UTskCzLY3inU0/DX30h2QhXse/Y3rAJpsaaNweqVhvZwZlMUovtyBu7pnGSpSo8CLhVOBg==`
+- npm shasum: `c182b09945eee8cd85d817b7ce4965784731fd49`
+- same-SHA six-target compatibility run: [`31352965430`](https://github.com/revazi/pi-career/actions/runs/31352965430)
+- OIDC publication run: [`31353182855`](https://github.com/revazi/pi-career/actions/runs/31353182855)
+- npm publisher identity: GitHub Actions trusted publisher for `revazi/pi-career`, workflow `release.yml`, environment `npm`
+- SLSA provenance subject and resolved Git dependency: exact `pi-career@0.2.0` tarball and commit above
+- custom GitHub Release assets: none
 
-For `v0.1.0`, sole maintainer Revaz Zakalashvili reviewed the evidence above and recorded **APPROVED** for both packaged targets. This is a maintainer release decision, not independent review or legal advice.
+The first tag-triggered attempt, run [`31352716654`](https://github.com/revazi/pi-career/actions/runs/31352716654), failed before dependency installation or publication because `shell: node {0}` resolved a relative ESM import from GitHub's temporary script directory. Registry absence was reconfirmed; no publish retry occurred. PR [#23](https://github.com/revazi/pi-career/pull/23) moved the hosted-gate query into a checked-in script. After explicit incident authorization, the unpublished tag was replaced once on the corrected candidate.
 
-### 3. Upstream artifact-expiry decision
+In run `31353182855`, every gate and the OIDC `npm publish` step succeeded. The run then failed closed before GitHub Release creation because npm's attestation endpoint propagated after the original one-minute bound and the resulting SLSA bundle used the current Sigstore v0.3 media type while npm's publish attestation remained v0.2. The version already existed authoritatively, so it was never rerun or republished. PR [#24](https://github.com/revazi/pi-career/pull/24) extended bounded propagation polling and validates both exact bundle formats. The corrected verifier subsequently proved registry metadata, tarball bytes, trusted-publisher identity, provenance workflow/tag/SHA, and latest dist-tag; exact published Pi install/load/runtime/offline/remove acceptance passed before the GitHub Release and deployment status were finalized.
 
-The imported binaries and provenance remain tracked and hash-verified in this repository, but the original Career Core Actions artifacts were ephemeral:
+**Never rerun or republish after an ambiguous publish response.** Query authoritative registry state first. A post-publication recovery may finish verification and release-channel bookkeeping only; it must not create an alternate publication path, overwrite an immutable npm version, or move the published tag.
 
-| Artifact ID | Target | GitHub-reported expiry |
-|---:|---|---|
-| `8910079991` | `darwin-arm64` | `2026-08-07T21:43:37Z` |
-| `8910084163` | `linux-x64-gnu` | `2026-08-07T21:43:47Z` |
+## Release gates
 
-Before npm publication, a human must recheck artifact availability and explicitly decide whether the tracked binaries, per-target provenance, manifest, archive identities/hashes, and public Core commit are sufficient durable provenance after expiry. If they are not sufficient, release stays blocked pending a separately approved preservation plan. The release process does not download, copy, upload, recreate, or relabel either artifact.
+A skipped, unknown, stale, or merely planned result is not a pass.
 
-For `v0.1.0`, sole maintainer Revaz Zakalashvili rechecked both artifacts on 2026-08-06 and recorded **SUFFICIENT**: the tracked binaries, per-target provenance, manifest, archive identities/hashes, public Core commit, and package verification are accepted as the durable evidence after upstream expiry.
+### 1. Freeze and review the exact candidate
+
+- Start from synchronized public `main` and identify one full candidate SHA.
+- Require a clean Git tree and no divergence from `origin/main`.
+- Confirm `package.json`, the root package-lock entries, the Skill metadata, package assertions, changelog, README, and release documentation all identify the candidate version where appropriate.
+- Keep Career Core and `@revazi/career` compatibility coordinates at exact `0.2.0` unless a separate compatibility/provenance review explicitly updates them; do not confuse the adapter release version with the external runtime version.
+- Confirm `package.json` is explicitly public only at `https://registry.npmjs.org/`, has `os` exactly `['darwin', 'linux']`, has exactly four wildcard Pi peers, declares no production/optional/bundled dependency tree, and has no lifecycle/publication script.
+- Ensure the candidate contains no real resume, vacancy, credentials, Pi session, provider output, generated local path, npm token, or unreviewed executable.
+- Review the complete diff from the prior release tag, including authoritative `src/`, generated `dist/index.js`/`dist/pdf-worker.js`, `career_run`, all three exact raw tools, slash commands, external resolver, Skill, release automation, and package documentation.
+- Do not move the candidate after local/hosted evidence is recorded. Any content change creates a new candidate and requires the gates again.
 
-### 4. Clean production and full audits
+### 2. Review the external runtime boundary
 
-`npm run audit:production` must pass with zero package-owned production vulnerabilities and `npm run audit:full` must pass with zero vulnerabilities across the complete development/host-Pi tree, both at explicit `--audit-level=low`. The production audit omits development, optional, and peer trees because the tarball owns no runtime dependency tree; strict package checks separately prove there is no `node_modules` or Pi package content and that exactly four wildcard peers remain external.
+- Confirm unsupported local/Git extension initialization registers no command/tool and fails with stable payload-free `unsupported_platform` before explicit/PATH lookup, package validation, acquisition, compatibility probing, or private stdin; retain invocation/resolver guards as defense in depth.
+- Confirm the only acquisition coordinate remains exact `@revazi/career@0.2.0` from the canonical npm registry.
+- Confirm runtime order remains: absolute `CAREER_CLI_PATH`, PATH `career`, package-local exact launcher, then bounded exact-package acquisition unless `PI_OFFLINE=1`.
+- Confirm every caller-controlled route must pass the exact managed Core 0.2.0 operation catalog and required self-contained schema bundles before private stdin opens.
+- Confirm package-local/acquired routes validate the exact ordered six-package v2 launcher manifest and delegate native target/libc/provenance/mode/size/format/architecture/SHA-256 verification to the reviewed launcher on the six supported targets.
+- Confirm the external release's launcher plus six native packages remain version-lockstep, have canonical registry integrity and SLSA v1 provenance, and are bound to reviewed Core commit `536690632884c17336cc3c108f1bba0f254b862b`.
+- Run the exact-package integration test on the six hosted macOS/GNU Linux/musl Linux release targets. Updating the external package coordinate, supported native target list, launcher schema, or managed Core contract requires separate compatibility, provenance, audit, and package review before this gate can pass.
 
-Both audits invoke `process.execPath` plus the absolute npm CLI derived from the real Node installation, verify any inherited `npm_execpath`, remove omit/include/audit-level/`NODE_ENV` overrides, strictly parse bounded JSON, and reject duplicate decoded keys. `npm run check:publish` is the authoritative readiness gate but performs no publication. It is a direct Node orchestrator with no nested npm command and requires both clean audits plus extracted package/load/install proof. Pack uses the trusted absolute npm CLI; listing and extraction use verified root-owned absolute `/usr/bin/tar`, never PATH-selected tools.
+### 3. Require clean audits and strict package proof
 
-The former temporary development/host-Pi acceptance was explicitly retired after upgrading the Pi development baseline to `0.84.0`; no accepted-audit file or validator remains. Do not use `npm audit fix --force`, downgrade the Pi baseline, override or patch the published Pi shrinkwrap, hand-edit lock entries, or add a replacement acceptance. A future finding blocks publication until remediated.
+`npm run audit:production` and `npm run audit:full` must both report zero vulnerabilities at explicit `--audit-level=low`. No audit acceptance baseline is allowed.
 
-### 5. Complete verification on the frozen SHA
+`npm run check:publish` must prove:
+
+- both strict audits are clean;
+- trusted npm is derived from the real Node installation and conflicting `npm_execpath` is rejected;
+- npm environment overrides and duplicate decoded JSON keys cannot weaken checks;
+- package listing/extraction uses verified absolute `/usr/bin/tar`;
+- the tarball matches the exact allowlist and size bounds and declares `os: ['darwin', 'linux']`;
+- no native runtime, `node_modules`, Pi peer contents, production dependency tree, or lifecycle/publication script is present;
+- extracted package loading, stable offline failure, and isolated Pi install/list/remove behavior pass.
+
+Do not use `npm audit fix --force`, downgrade the Pi baseline, hand-edit third-party lock entries, or add an acceptance file. A future vulnerability blocks release until remediated.
+
+### 4. Run complete verification on the frozen SHA
 
 Run with Node.js 22.19 or newer:
 
 ```bash
 npm ci
 npm run build
-git diff --exit-code -- dist/index.js
+git diff --exit-code -- dist/index.js dist/pdf-worker.js
+npm run bench:tokens
+npm run bench:tokens:compare
 npm run check
-npm run test:bundled-runtime
+npm run test:runtime-resolution
+npm run test:career-package
 npm run audit:production
 npm run audit:full
 npm run check:publish
@@ -86,37 +120,73 @@ git diff --check
 
 Requirements:
 
-- `npm run build` may reproduce tracked `dist/index.js`; it must not alter runtime artifacts. The immediate dist diff must pass.
-- All project/runtime/package/offline checks and both zero-vulnerability audits must pass, the runtime npm tree must remain empty, and `npm run check:publish` must pass.
-- Compatibility must execute against an explicitly reviewed fixture checkout; a skip is not release evidence.
-- No audit acceptance or not-clean full-audit claim is permitted.
-- The exact final SHA must then pass both required hosted native jobs: `darwin-arm64` on macOS arm64 and `linux-x64-gnu` on Linux x64 glibc.
+- The immediate dist diff after `npm run build` must pass; a later reproducibility test alone does not prove the candidate committed the generated output.
+- Token measurements must satisfy the active before/optimizing/after manifest: immutable Git-history snapshot/manifest bytes and source/Skill tree anchors, exact frozen before/after comparability and deltas, unchanged current shape/invariants/budgets, and no current workflow regression relative to the frozen after snapshot. Later current source need not equal the historical after tree.
+- Exact-package acquisition must execute managed discovery plus representative synthetic resume/job operations.
+- Compatibility must run against an explicitly reviewed fixture checkout. A skip is not release evidence.
+- The production npm tree must remain empty apart from unmet external peers expected in the Pi host.
+- No command may create a repository tarball, native runtime, payload/result file, audit-acceptance baseline, or publication side effect. Reviewed synthetic token snapshots are benchmark evidence, not vulnerability acceptance.
+
+### 5. Require hosted checks on the same SHA
+
+Main branch protection must require the strict, up-to-date `Adapter checks` context. That ordinary pull-request job proves the build, deterministic adapter tests, native-free package, offline loading/install, and diff checks without acquiring or executing the external Career package.
+
+The costly six-target matrix is not an automatic pull-request check. After freezing the final SHA on public `main`, manually dispatch `.github/workflows/external-career.yml` on that exact ref and require all six native GitHub checks:
+
+```bash
+gh workflow run external-career.yml --ref main
+```
+
+- `External Career package (darwin-arm64)`;
+- `External Career package (darwin-x64)`;
+- `External Career package (linux-x64-gnu)`;
+- `External Career package (linux-arm64-gnu)`;
+- `External Career package (linux-x64-musl)`;
+- `External Career package (linux-arm64-musl)`.
+
+Record the dispatched run's `headSha` and reject it unless it equals the frozen release SHA. The macOS arm64 and Linux x64 GNU jobs execute the complete release ladder, including immediate dist reproducibility, clean audits, native-free package proof, offline smokes, and diff checks. Every target job executes a native Node build, exact launcher acquisition, managed contracts, representative synthetic resume/job operations, runtime resolver checks, and offline package load. Dispatch this matrix for external package coordinate, launcher/platform catalog, runtime resolver, managed Core contract, and release reviews—not for unrelated ordinary pull requests.
+
+### 6. Finalize release-facing text
 
-### 6. Finalize notes only after all other gates pass
+Before release authorization:
 
-After every preceding gate passes, a separately committed finalization change must:
+- convert `CHANGELOG.md` candidate notes to a dated candidate-version entry;
+- ensure README installation uses the exact candidate `npm:pi-career@<version>` coordinate and clearly distinguishes historical releases;
+- state that pi-career packages no native runtime, supports only the six reviewed macOS/Linux targets, uses exact external `@revazi/career@0.2.0`, and validates its exact ordered six-package v2 manifest;
+- state that both production and complete development/host-Pi audits are clean at the explicit low threshold;
+- keep all full commit SHA and npm integrity placeholders out of tracked files until those values exist; record them in the GitHub Release after publication.
 
-- convert the candidate notes to a dated `0.1.0` entry;
-- preserve unsigned/not-notarized runtime caveats and the two supported targets;
-- state that `pi-career@0.1.0` is the public npm package and that there is no crate publication or custom release asset; and
-- state that both the package-owned production audit and complete development/host-Pi audit are clean at the explicit low threshold.
+The finalization commit cannot contain its own SHA. Only the separately authorized final clean commit may be published and receive `<tag>`.
 
-A commit cannot contain its own Git SHA. After the finalization commit exists, record its full SHA in the GitHub Release notes and verify npm's `gitHead` against it. Only that separately authorized final commit may receive the annotated tag, npm publication, and GitHub Release.
+## Manual pre-publication checks
 
-## Manual release execution
+Run these only on the frozen clean candidate:
 
-After all blocking gates pass on the final clean commit and the maintainer has explicitly authorized execution:
+1. Confirm npm package `pi-career` has exactly the GitHub Actions trusted publisher `revazi/pi-career`, workflow `release.yml`, environment `npm`.
+2. Confirm the GitHub `npm` environment exists and applies the reviewed deployment protections. No npm token or OTP may be stored in GitHub, npm configuration, repository files, Pi messages, logs, or release notes.
+3. Confirm `npm view pi-career@<version> version --json` reports no existing version. npm versions are immutable.
+4. Run trusted `npm pack --dry-run --json --ignore-scripts` or rely on the stricter recorded `check:publish` artifact proof.
+5. Record the candidate full SHA, package filename/size, clean audit results, hosted run URLs, and reviewed fixture SHA outside private content.
+6. Obtain explicit release authorization. Do not infer authorization from readiness work.
 
-1. Confirm `npm whoami` identifies the intended npm account and the registry is exactly `https://registry.npmjs.org/`. Never place an npm token or one-time password in repository files, Pi messages, logs, or release notes.
-2. Reconfirm that `npm view pi-career@0.1.0 version --json` returns not found. A registry name check does not reserve the name.
-3. Create and push the unsigned annotated `v0.1.0` tag for the exact final commit.
-4. From Node 22.19.0/npm 10.9.3, publish once with lifecycle scripts disabled:
+## Authorized release execution
 
-   ```bash
-   npm publish --access public --tag latest --ignore-scripts
-   ```
+Only after every gate passes and the maintainer explicitly authorizes release execution:
 
-5. Verify `npm view pi-career@0.1.0 --json` reports the expected version, repository, four peers, tarball integrity, and `gitHead`; then perform an isolated `pi install npm:pi-career@0.1.0`, package load, bundled-runtime smoke, and removal on a supported target.
-6. Create the GitHub Release from `v0.1.0`. State the full commit SHA, npm registry integrity, supported targets, unsigned/not-notarized binaries, no crate/custom assets, zero-vulnerability package-owned production and complete development/host-Pi audits at the explicit low threshold, and that native-license evidence received sole-maintainer self-review rather than independent legal review.
+1. Reconfirm the clean SHA, branch protection checks, trusted-publisher/environment configuration, canonical registry, and absence of `pi-career@<version>`.
+2. Create one annotated unsigned `<tag>` on the exact candidate and push only that tag. The tag is the immutable input that triggers `.github/workflows/release.yml`; the workflow must never create or move it.
+3. The workflow must verify the tag/version/changelog/SHA, install exact trusted-publishing-compatible npm tooling, run the complete package publication gate, and publish with lifecycle scripts disabled, public/latest coordinates, and npm provenance through OIDC.
+4. If publication returns an ambiguous response, query the registry before any rerun. Never move the tag, attempt to overwrite the version, or blindly republish.
+5. Before creating the GitHub Release, the workflow must verify registry metadata: version, repository, four wildcard peers, no dependency tree/lifecycle scripts, tarball integrity, shasum, provenance, and `gitHead` equal to the tagged candidate SHA.
+6. The workflow must create the GitHub Release from the existing `<tag>` with:
+   - full commit SHA;
+   - npm integrity and shasum;
+   - exact external `@revazi/career@0.2.0` coordinate;
+   - all six supported macOS, GNU Linux, and musl Linux targets, plus a clear note that only the launcher is a pi-career installation surface;
+   - native-free pi-career package statement;
+   - clean production/full audit statement;
+   - no crate publication, signing/notarization claim, or custom release asset.
+7. In an isolated Pi agent directory, install exact `npm:pi-career@<version>`, list/load it, exercise exact-package runtime acquisition with synthetic operations on a supported target, test offline failure, and remove it.
+8. Recheck the npm dist-tag, Git tag target, GitHub Release target, provenance, and main CI after all channels settle.
 
-Do not sign, attach assets, change repository settings, publish another registry tag/version, or retry after an ambiguous registry response without first querying the registry. npm versions are immutable; a failed post-publication check is an incident, not permission to overwrite `0.1.0`.
+Do not sign, attach assets, change repository visibility, add an alternate publication workflow or token-based path, publish another registry tag/version, or retry an ambiguous operation without first querying authoritative state. A failed post-publication check is an incident, not permission to replace the immutable published version.

package/{runtime/LICENSE-MIT → docs/unpdf-LICENSE-MIT.txt}

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Revaz Zakalashvili
+Copyright (c) 2023-PRESENT Johann Schopplich
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal