@pieai/pro-gov 0.3.3

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 PieAI
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,47 @@
+# @pieai/pro-gov
+
+Project-level distribution kit for Project Governance System.
+
+`@pieai/doc-gov` remains the validator package. `@pieai/pro-gov` ships reusable
+project-governance assets and a conservative project-level CLI. It is the
+package that answers: "What starter/profile material does this project need,
+and what would change if we adopted it?"
+
+## Install
+
+```bash
+pnpm add -D @pieai/pro-gov @pieai/doc-gov
+```
+
+Add scripts in the target project:
+
+```json
+{
+  "scripts": {
+    "pro-gov": "pro-gov",
+    "doc-gov": "doc-gov"
+  }
+}
+```
+
+## Commands
+
+```bash
+pro-gov assets list
+pro-gov init --profile engineering-runtime --dry-run
+pro-gov init --profile doc-only --dry-run
+pro-gov sync --check
+pro-gov doctor
+```
+
+The first release is read-only by default. It reports what would change before
+any future write path is added.
+
+## Package Boundary
+
+- `pro-gov` lists and compares starter/profile/integration assets.
+- `doc-gov` validates governed Markdown, router integrity, manifest freshness,
+  links, local hooks, and CI wiring.
+- Project-local product truth stays in the target project.
+- Write-mode install or upgrade behavior is intentionally not enabled in the
+  first release.

package/assets/docs/reference/adoption/adoption-playbook.md

@@ -0,0 +1,215 @@
+---
+id: REF-ADOPTION-PLAYBOOK
+title: Project Governance System Adoption Playbook
+type: reference
+status: stable
+canonical: true
+owner: human
+created: 2026-05-06
+last_reviewed: 2026-06-13
+domain: adoption
+tags:
+  - adoption
+  - migration
+  - profiles
+pinned: false
+related:
+  - POLICY-SYNC-STRATEGY
+  - REF-PROJECT-RELATIONSHIP
+---
+
+# Adoption Playbook
+
+Use this when a project wants to migrate into the Project Governance System.
+
+## The Short Version
+
+1. Pick one profile.
+2. Inventory the project's current docs/rules.
+3. Install the governance packages.
+4. Add starter `docs/governance/` and `docs/policy/` files.
+5. Add the selected `docs/governance/agents-routing/` profile rule.
+6. Move current truth into the governed layers.
+7. Archive or delete old systems.
+8. Run validation.
+
+Do not migrate by slowly adding random files. Migrate by making one clear current work surface.
+
+## Step 1: Pick A Profile
+
+| Project kind | Profile |
+| --- | --- |
+| App / game / runtime / service / browser product | `engineering-runtime` |
+| IP / writing / research / AI media / asset library | `doc-only` |
+
+If unsure, pick `doc-only` first. Add engineering agents routing only when the project has real runtime/code behavior that needs lane-specific proof.
+
+## Step 2: Inventory Current Truth
+
+Before moving anything, list:
+
+- current project router files (`AGENTS.md`, `CLAUDE.md`, etc.)
+- current docs index files
+- current active plans/specs
+- current canon/reference/archive locations
+- old/legacy documentation roots
+- project-local runtime truth, if any
+
+## Step 3: Install The Governance Core
+
+Current package-based method:
+
+- install `@pieai/pro-gov` as the target project's project-level asset source
+- install `@pieai/doc-gov` as the target project's validator CLI source
+- preserve project-local package scripts
+- run `pro-gov init --profile <engineering-runtime|doc-only> --dry-run` to see
+  the starter files that would be installed
+- run `pro-gov sync --check` to compare reusable starter files without changing
+  the project
+- run `doc-gov migrate --profile <engineering-runtime|doc-only> --check` before
+  changing files so profile mismatches fail early
+- run `doc-gov router-check` after the sync so stale router/profile paths fail
+  mechanically
+- copy `starter/lefthook.template.yml` to `lefthook.yml` and
+  `starter/.github/workflows/docs-check.yml` to `.github/workflows/docs-check.yml`
+  when the target project is ready for standard guardrails
+- run `doc-gov doctor` after wiring guardrails to verify they are actually
+  connected
+- treat the npm package as the CLI source and the local `docs/governance/`
+  files as the project's checked-in governance contract
+
+Later Stage 2 method:
+
+```bash
+pnpm add -D @pieai/pro-gov @pieai/doc-gov
+```
+
+Do not jump to write-mode installation until package installation is
+deliberately enabled and the read-only checks are understood.
+Do not use an absolute-path script as the default for collaborators; it is fine
+for one local machine, but it is brittle once a repo moves or another person
+checks it out.
+
+Keep the upstream checkout path out of reusable project wiring. The central
+repository and local checkout currently use `ProjectGovernanceSystem`, while
+the private workspace package name is `pro-gov`. Target projects should use
+`@pieai/pro-gov` and `@pieai/doc-gov` for commands, use the canonical GitHub URL
+for public links, and refer to the source as the Project Governance System
+upstream repository.
+
+## Step 4: Add Starter Structure
+
+Use `starter/` as the reference, but keep local facts local.
+
+Required concepts:
+
+- `docs/reference/documentation-map.md`
+- `docs/governance/boundary.md`
+- `docs/governance/ssot-v0.9.md`
+- `docs/governance/doc-agent-rules.md`
+- `docs/governance/doc-types.md`
+- `docs/governance/agents-routing/<selected-profile>-v0.9.md`
+- `docs/governance/templates/*.md`
+- `docs/policy/best-practice-for-this-project.md`
+- `docs/reference/execution/current-work.md`
+- `docs/plans/active/`
+- `docs/plans/completed/`
+- `docs/specs/active/`
+- `docs/specs/completed/`
+- `docs/archive/`
+- `AGENTS.md` as the project router
+- `CLAUDE.md` as a thin adapter that forwards to `AGENTS.md`
+
+## Step 5: Apply The Profile
+
+### Engineering Runtime
+
+Add:
+
+- `docs/governance/agents-routing/engineering-runtime-v0.9.md`
+- engineering lane summary in `AGENTS.md`
+- detailed lane profile in `docs/policy/best-practice-for-this-project.md`
+
+The project must define local lanes and proof commands.
+Do not copy the upstream root `integrations/` directory into target projects by default.
+If a project needs local external-workflow guidance, keep it thin in `AGENTS.md` or put project-specific notes under `docs/reference/integrations/`.
+
+### Doc-Only
+
+Add:
+
+- `docs/governance/agents-routing/doc-only-v0.9.md`
+- `docs/governance/ssot-v0.9.md`
+- AI-in-the-Loop rules linked from the project's external shared-rule source
+- canon/provenance/archive rules in `docs/policy/best-practice-for-this-project.md`
+
+Do not add Superpowers TDD or Directed Development by default.
+
+## Step 6: Create Current Work
+
+Create or update:
+
+```text
+docs/reference/execution/current-work.md
+```
+
+This file answers:
+
+- What is active now?
+- Which plan/spec is current?
+- Where are completed proof records?
+- What should a new AI session read next?
+
+This is not the agents-routing algorithm.
+
+## Step 7: Retire Old Systems
+
+Old documentation systems must become one of:
+
+- migrated into the governed layers
+- archived under `docs/archive/`
+- deleted if stale and misleading
+
+Do not keep old and new current surfaces alive together.
+
+Do not migrate product artifacts into `docs/**` just because they are Markdown.
+Prompts, generated media notes, project-package canon, source assets, and
+workbench files stay in their product package unless the project explicitly opts
+them into doc-gov.
+
+For the v0.9 structural migration, use
+`docs/reference/adoption/migration-v0.9.md` as the checklist.
+
+## Step 8: Validate
+
+Minimum:
+
+```bash
+pnpm doc-gov check
+pnpm doc-gov router-check
+pnpm doc-gov scan --check
+pnpm doc-gov links
+pnpm doc-gov audit
+pnpm doc-gov doctor
+git diff --check
+```
+
+Engineering projects should also run their local verification ladder.
+
+## Example: Migrating A Runtime Product
+
+If the target project is an app/runtime project:
+
+1. Pick `engineering-runtime`.
+2. Inventory existing docs and current runtime truth.
+3. Install `@pieai/pro-gov` and `@pieai/doc-gov`, or keep the existing local
+   tool copy until the project is ready to move scripts and CI together.
+4. Add governed `docs/governance/` and `docs/policy/` starter files.
+5. Write `docs/policy/best-practice-for-this-project.md` with project-specific truth, stack, lanes, and verification commands.
+6. Create `docs/reference/execution/current-work.md`.
+7. Move current plans into `docs/plans/active/`; move finished plans into `docs/plans/completed/`.
+8. Move stable product truth into `docs/canon/`; guides into `docs/reference/`; historical material into `docs/archive/`.
+9. Delete or archive old parallel doc roots.
+10. Run validation and commit the migration as a clean checkpoint.
+
+If the project is mostly a docs/content workspace, start with `doc-only` instead and do not install engineering routing until real runtime work requires it.

package/assets/docs/reference/adoption/downstream-project-registry.md

@@ -0,0 +1,78 @@
+---
+id: REF-DOWNSTREAM-PROJECT-REGISTRY
+title: Downstream Project Registry
+type: reference
+status: active
+canonical: true
+owner: human
+created: 2026-06-09
+last_reviewed: 2026-06-13
+domain: adoption
+tags:
+  - downstream
+  - adoption
+  - registry
+pinned: false
+related:
+  - REF-PROJECT-RELATIONSHIP
+  - POLICY-SYNC-STRATEGY
+---
+
+# Downstream Project Registry
+
+This registry is the central Project Governance System ledger for known local
+projects that have adopted this system.
+
+It records governance adoption state, not product truth. Product plans, runtime
+details, IP canon, audit outputs, and project-specific policies remain in the
+downstream projects.
+
+## Registry Rules
+
+- Update this file when a project adopts, leaves, renames, or changes profile.
+- Treat package versions as the versions installed in the downstream project's
+  `package.json`. Existing rows may list only `doc-gov` until that project is
+  intentionally synced to `pro-gov`.
+- Treat health as a snapshot. A project can be on the latest version but still
+  have local working-tree cleanup in progress.
+- Do not add a project-specific profile here unless at least two projects need
+  the same reusable profile.
+- Do not use this registry to freeze the upstream local checkout path. The
+  current local upstream folder may be `ProjectGovernanceSystem`, but downstream
+  governed docs should prefer `@pieai/doc-gov`, `@pieai/pro-gov`, and "Project
+  Governance System upstream repository" wording over machine-local paths.
+
+## Current Downstream Projects
+
+Checked on 2026-06-09.
+
+| Project | Local path | Profile | Installed doc-gov | Health snapshot | Notes |
+| --- | --- | --- | --- | --- | --- |
+| Non-Heroes | `/Users/yuanfei/PieAI/Non-Heroes` | `engineering-runtime` | `0.3.2` | Partial | Package and router are current; local doc migration work is in progress, so `doctor` currently fails on moved/archive reference docs until that project is cleaned up. |
+| Show | `/Users/yuanfei/PieAI/Show` | `engineering-runtime` | `0.3.2` | Healthy | `router-check` and `doctor` pass. |
+| PieFlow | `/Users/yuanfei/PieAI/PieFlow` | `engineering-runtime` | `0.3.2` | Healthy | `router-check` and `doctor` pass. |
+| story-creator | `/Users/yuanfei/PieAI/_NovelFrameworks/story-creator` | `engineering-runtime` | `0.3.2` | Healthy | Uses engineering routing because the repository contains a TypeScript CLI, tests, hooks, gates, and writing-system runtime. |
+| PieAIStudio-Site | `/Users/yuanfei/PieAI/PieAIStudio-Site` | `engineering-runtime` | `0.3.2` | Healthy | `router-check` and `doctor` pass. |
+| PieHQ | `/Users/yuanfei/PieAI/PieHQ` | `doc-only` | `0.3.2` | Healthy | `router-check` and `doctor` pass; unrelated FounderLogs work is present locally. |
+| PieIP | `/Users/yuanfei/PieAI/PieIP` | `doc-only` | `0.3.2` | Healthy | `router-check` and `doctor` pass. |
+| ProjectLens | `/Users/yuanfei/PieAI/ProjectLens` | `doc-only` | `0.3.2` | Healthy | `router-check` and `doctor` pass; ProjectLens is a project-level audit workspace, not a runtime product. |
+
+## Representative Examples
+
+The `examples/` directory is not the full registry. It contains representative
+case studies:
+
+- `examples/non-heroes/example.md` for an engineering-runtime product.
+- `examples/pieflow/example.md` for a complex app/runtime product.
+- `examples/pieip/example.md` for a doc-only AI media / asset-governance
+  project.
+
+Add a new example only when a project teaches a reusable adoption pattern that
+the existing examples do not cover.
+
+## Removal / Rename Notes
+
+- `Supa` is no longer tracked here because that project was renamed/replaced by
+  `Non-Heroes`.
+- GitNexus is intentionally absent. It has been removed from the central system
+  and should not be reintroduced through downstream policy links.

package/assets/docs/reference/adoption/migration-v0.9.md

@@ -0,0 +1,74 @@
+---
+id: REF-MIGRATION-V0-9
+title: Project Governance System v0.9 Migration Checklist
+type: reference
+status: stable
+canonical: true
+owner: human
+created: 2026-05-09
+last_reviewed: 2026-06-04
+domain: adoption
+tags:
+  - migration
+  - v0.9
+  - router-check
+pinned: false
+related:
+  - REF-ADOPTION-PLAYBOOK
+  - POLICY-VERSIONING
+---
+
+# v0.9 Migration Checklist
+
+Use this checklist when moving a project from the older root `governance/` or
+`routing/` shape to the current Project Governance System boundary.
+
+## Required Moves
+
+Move documentation governance into `docs/governance/`:
+
+- `governance/agent-rules.md` -> `docs/governance/doc-agent-rules.md`
+- `governance/doc-types.md` -> `docs/governance/doc-types.md`
+- `governance/README.md` -> `docs/governance/boundary.md`
+- `governance/MANIFEST.yml` -> `docs/governance/MANIFEST.yml`
+- `governance/templates/` -> `docs/governance/templates/`
+
+Move project AI/development policy into `docs/policy/`:
+
+- `governance/best-practice-for-this-project.md` -> `docs/policy/best-practice-for-this-project.md`
+- `governance/refactor-rules.md` -> `docs/policy/refactor-rules.md`
+- eligible `governance/shared-rules/` entries -> `docs/policy/shared-rules/`,
+  preferably as links to their external SSOT sources. Skip `ssot.md` and
+  `task-routing.md`; those move into `docs/governance/` as listed below.
+
+Move reusable governance rules into the new core:
+
+- old SSOT rule -> `docs/governance/ssot-v0.9.md`
+- old task routing rule -> selected file under `docs/governance/agents-routing/`
+
+## Required Deletions
+
+After the move, these should not exist:
+
+- root `governance/`
+- root `routing/`
+- `starter/governance/`
+- `docs/policy/shared-rules/ssot.md`
+- `docs/policy/shared-rules/task-routing.md`
+- non-root `README.md` under governed docs
+
+## Required Checks
+
+```bash
+pnpm doc-gov check
+pnpm doc-gov router-check
+pnpm doc-gov scan --check
+pnpm doc-gov links
+pnpm doc-gov audit
+pnpm doc-gov doctor
+git diff --check
+```
+
+For engineering projects, also run the project's normal typecheck/test/build
+ladder. For doc-only projects, run the project's content/workbench validation
+commands.

package/assets/docs/reference/adoption/project-relationship.md

@@ -0,0 +1,128 @@
+---
+id: REF-PROJECT-RELATIONSHIP
+title: Project Governance System Project Relationship Model
+type: reference
+status: stable
+canonical: true
+owner: human
+created: 2026-05-06
+last_reviewed: 2026-06-13
+domain: adoption
+tags:
+  - ownership
+  - upstream
+  - project-local
+pinned: false
+related:
+  - POLICY-UPSTREAMING
+  - POLICY-SYNC-STRATEGY
+---
+
+# Project Relationship Model
+
+This file answers the most important beginner question:
+
+> If Non-Heroes already has doc-gov, and this central repo now exists, who owns what?
+
+## Short Answer
+
+The central repo owns the **engine**. Each project owns its **local product content**.
+
+| Thing | Owner |
+| --- | --- |
+| Status lifecycle, document types, SSOT, agents routing, CLI checks, templates | Project Governance System upstream repository |
+| Non-Heroes product plans, runtime canon, product rules | Non-Heroes |
+| PieFlow product truth, connector rules, browser lanes | PieFlow |
+| PieIP character/script/asset governance | PieIP |
+| Current downstream adoption list and health snapshot | `docs/reference/adoption/downstream-project-registry.md` |
+
+## Naming And Checkout Paths
+
+Keep these identities separate:
+
+- **System name:** Project Governance System.
+- **Local upstream checkout:** currently `ProjectGovernanceSystem`.
+- **GitHub repository slug:** `ProjectGovernanceSystem`.
+- **Private workspace package name:** `pro-gov`.
+- **Published validator package:** `@pieai/doc-gov`.
+- **Project-level distribution package:** `@pieai/pro-gov`.
+
+A local folder rename should not force downstream projects to rewrite package
+names or CLI commands. If the GitHub repository slug changes, downstream public
+links and repository remotes should use the canonical repository URL. Downstream
+projects should point to the package and the upstream repository concept, not to
+a hard-coded local checkout path. If a local automation or handoff prompt truly
+needs a clone path, write it as `<local ProjectGovernanceSystem checkout path>`
+and keep it out of reusable router text.
+
+## Does Non-Heroes Now Import This Repo?
+
+Not yet automatically.
+
+Known downstream projects are listed in
+`docs/reference/adoption/downstream-project-registry.md`.
+
+Originally Non-Heroes, PieFlow, and PieIP had local working copies because the
+system was born inside active projects. This central repo is now the upstream
+source, and downstream projects should use `@pieai/doc-gov`, `@pieai/pro-gov`,
+and their selected profile instead of keeping private CLI or starter copies.
+
+## Why Not Auto-Symlink Everything?
+
+Because project governance has two kinds of files:
+
+1. **Shared/core files** that can be linked or packaged.
+2. **Project-local files** that must stay local.
+
+The old `governance/` folder mixed both kinds. The clearer split is:
+
+- `docs/governance/` contains doc-system rules, SSOT, agents-routing, document types, templates, and manifest.
+- `docs/policy/` contains project-local AI development policy, lane wording, proof commands, and truth hierarchy.
+
+Symlinking or copying the whole policy layer would be wrong because Non-Heroes and PieFlow need different local lane profiles. The safe rule:
+
+- shared rules may be symlinked
+- doc-gov core should become the installed validator package
+- pro-gov should become the installed project-level asset package
+- project profiles are templates
+- project-local best-practice files remain in each project's `docs/policy/`
+- product artifacts outside `docs/**` stay in the product package unless a project explicitly opts them into doc-gov
+
+## How Non-Heroes Improvements Flow Upstream
+
+When Non-Heroes discovers a better governance rule:
+
+1. Ask: is this core, profile, or Non-Heroes-local?
+2. If core, update this repo.
+3. If profile, update the relevant `profiles/**`.
+4. If Non-Heroes-local, keep it in Non-Heroes.
+5. Other projects then upgrade from this central source.
+
+Example:
+
+- An active project discovered active plans were piling up.
+- The generic fix is a `completed` lifecycle state.
+- Therefore `completed` belongs in this repo's doc-gov core.
+
+## How PieFlow And PieIP Upgrade
+
+Use an explicit migration task:
+
+1. Pick the profile:
+   - engineering-runtime projects: apps, services, runtimes, websites, games,
+     CLIs, and behavior-critical systems
+   - doc-only projects: IP, research, audit, media, and asset-governance
+     workspaces without behavior-critical runtime work
+2. Confirm the project uses `@pieai/doc-gov` as its validator source.
+3. Confirm the project can inspect `@pieai/pro-gov` assets with
+   `pro-gov assets list`.
+4. Compare local `docs/governance/` and `docs/policy/` starter docs against
+   packaged starter assets.
+5. Compare selected local agents-routing against `docs/governance/agents-routing/`.
+6. Compare local shared AI work rules against their external SSOT targets, such
+   as symlinked files under `docs/policy/shared-rules/`.
+7. Keep project-local docs and product artifacts local.
+8. Run project validation.
+
+This is AI-assisted comparison now. Later, write-mode installation can become a
+`pro-gov` command after the read-only checks prove safe.

package/assets/docs/reference/adoption/public-release-checklist.md

@@ -0,0 +1,123 @@
+---
+id: REF-PUBLIC-RELEASE-CHECKLIST
+title: Public Release Checklist
+type: reference
+status: stable
+canonical: true
+owner: human
+created: 2026-06-04
+last_reviewed: 2026-06-13
+domain: adoption
+tags:
+  - release
+  - npm
+  - github
+pinned: false
+related:
+  - POLICY-SYNC-STRATEGY
+  - POLICY-VERSIONING
+---
+
+# Public Release Checklist
+
+Use this before making the repository public or publishing `@pieai/doc-gov` or
+`@pieai/pro-gov`.
+
+## Mental Model
+
+Making the GitHub repository public is like opening the workshop doors. People
+can inspect the benches, the notes, and the commit history.
+
+Publishing to npm is like putting a tool on a public shelf. People can install
+it without cloning the workshop.
+
+Both need checks, but they are not the same release.
+
+## Repository Public Checklist
+
+Before changing GitHub visibility:
+
+- current working tree is clean
+- current branch is pushed
+- current files have no secrets
+- Git history has no real secrets
+- current files have no machine-local startup paths
+- root README explains the project to outsiders
+- license and security contact exist
+- CI is present and runs the standard doc-gov gate
+
+Recommended commands:
+
+```bash
+git status --short --branch
+pnpm typecheck
+pnpm test
+pnpm build
+pnpm doc-gov doctor
+git diff --check
+```
+
+## npm Publish Checklist
+
+Before publishing:
+
+- `packages/doc-gov/package.json` has public package metadata
+- `packages/pro-gov/package.json` has public package metadata
+- each package has a README
+- each package has a license
+- each package has a built executable under `dist/cli.js`
+- package dry-runs show only intended files
+- publish `@pieai/doc-gov` before `@pieai/pro-gov` when both package versions
+  are new, because `pro-gov` depends on the matching validator release
+- maintainer is authenticated to npm
+- registry is the official npm registry, not a mirror
+- scoped publish uses public access
+
+Recommended commands:
+
+```bash
+npm whoami --registry https://registry.npmjs.org/
+
+pnpm --filter @pieai/doc-gov pack --dry-run
+pnpm --filter @pieai/pro-gov pack --dry-run
+
+pnpm --filter @pieai/doc-gov publish --access public --registry https://registry.npmjs.org/
+npm view @pieai/doc-gov version --registry https://registry.npmjs.org/
+
+pnpm --filter @pieai/pro-gov publish --access public --registry https://registry.npmjs.org/
+npm view @pieai/pro-gov version --registry https://registry.npmjs.org/
+```
+
+Important: do not claim an npm package is live until its `npm view <package>
+version` command resolves from the public registry.
+
+## After Release
+
+After GitHub and npm are live:
+
+- verify the GitHub URL in a browser or with `gh repo view`
+- verify npm versions with `npm view @pieai/doc-gov version` and
+  `npm view @pieai/pro-gov version`
+- update downstream projects only through an explicit sync task
+- update public website copy from the current README and this checklist, not
+  from stale chat history
+
+## Future: Trusted Publishing
+
+The first release may be published from a logged-in maintainer machine. Future
+releases should move to npm Trusted Publishing through GitHub Actions.
+
+Recommended future setup:
+
+1. On npmjs.com, open the package settings for `@pieai/doc-gov` and
+   `@pieai/pro-gov`.
+2. Add a Trusted Publisher for GitHub Actions to each package:
+   - owner: `PieAIStudio`
+   - repository: `ProjectGovernanceSystem` (GitHub slug)
+   - workflow file: `npm-publish.yml`
+3. Keep the workflow as manual `workflow_dispatch` until the first trusted
+   publishing run succeeds.
+4. After that, optionally add a release-tag trigger such as `v0.3.1`.
+
+Trusted Publishing gives npm a verifiable GitHub build origin and avoids
+long-lived npm tokens.