@pieai/pro-gov 0.3.7 → 0.3.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pieai/pro-gov",
-  "version": "0.3.7",
+  "version": "0.3.8",
   "description": "Project-level distribution kit for Project Governance System.",
   "keywords": [
     "ai-agents",
@@ -35,7 +35,7 @@
     "access": "public"
   },
   "dependencies": {
-    "@pieai/doc-gov": "^0.3.7"
+    "@pieai/doc-gov": "^0.3.8"
   },
   "devDependencies": {
     "@types/node": "24.13.2",

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

@@ -1,153 +0,0 @@
----
-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-30
-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
-
-### AI Release Rule
-
-The only supported release path for this repository is GitHub Actions Trusted
-Publishing:
-
-1. Verify both package versions are aligned and all local checks pass.
-2. Commit and push the release-ready state to `main`.
-3. Run `gh workflow run npm-publish.yml --ref main`.
-4. Monitor the workflow to completion.
-5. Confirm both versions from the official registry with `npm view`.
-
-Do not run `npm publish` locally and do not create or reuse a long-lived npm
-write token for this repository. Since December 2025, `npm login` creates a
-short-lived session (currently two hours), not a durable release credential.
-Local `npm whoami` therefore tests only local token authentication; it does not
-report whether GitHub OIDC Trusted Publishing is configured or healthy.
-
-Beginner version: pushing `main` makes the approved code available to the
-release workflow, but it does not publish automatically. The explicit
-`gh workflow run` command is the final safety switch. GitHub then proves the
-workflow identity to npm and obtains a short-lived credential for that one
-release.
-
-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
-- npm Trusted Publisher is configured for both packages
-- registry is the official npm registry, not a mirror
-- scoped publish uses public access
-
-Recommended local verification:
-
-```bash
-pnpm --filter @pieai/doc-gov pack --dry-run
-pnpm --filter @pieai/pro-gov pack --dry-run
-```
-
-Recommended publish command:
-
-```bash
-gh workflow run npm-publish.yml --ref main
-```
-
-Important: do not claim an npm package is live until its `npm view <package>
-version` command resolves from the public registry.
-
-## Trusted Publishing Setup
-
-npm publishing should use Trusted Publishing through GitHub Actions. This is the
-smooth path: GitHub Actions proves to npm that a specific workflow in this
-repository is publishing the package, so maintainers do not need to pass a
-long-lived npm token around.
-
-Set this once for each package on npmjs.com:
-
-1. Open the package settings for `@pieai/doc-gov`.
-2. Add a Trusted Publisher for GitHub Actions:
-   - owner: `PieAIStudio`
-   - repository: `ProjectGovernanceSystem`
-   - workflow file: `npm-publish.yml`
-   - allowed action: `npm publish`
-3. Repeat the same setup for `@pieai/pro-gov`.
-4. Keep the workflow as manual `workflow_dispatch` until several releases have
-   succeeded.
-
-The workflow must keep:
-
-- `permissions.id-token: write`
-- a GitHub-hosted runner
-- npm CLI `11.5.1` or newer
-- package `repository` fields that match the public GitHub repository
-- `pnpm pack` before publish, so workspace dependencies are converted in the
-  tarball
-- `npm publish <tarball> --provenance --access public`
-
-## 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

package/assets/docs/reference/adoption/site-publication-brief.md

@@ -1,94 +0,0 @@
----
-id: REF-SITE-PUBLICATION-BRIEF
-title: Website Publication Brief
-type: reference
-status: stable
-canonical: true
-owner: human
-created: 2026-06-04
-last_reviewed: 2026-06-13
-domain: adoption
-tags:
-  - website
-  - public
-  - handoff
-pinned: false
-related:
-  - REF-PUBLIC-RELEASE-CHECKLIST
-  - REF-PROJECT-RELATIONSHIP
----
-
-# Website Publication Brief
-
-Use this when asking the PieAI Studio website project to add Project Governance
-System as a public project page.
-
-## Public Positioning
-
-Project Governance System keeps long-running AI-assisted projects understandable
-and governable.
-
-Beginner-friendly description:
-
-> AI can create plans, specifications, rules, and reports faster than people can
-> organize them. Project Governance System is the librarian, traffic desk, and
-> inspection machine: it keeps current truth easy to find, sends each task down
-> the right route, and checks that important project evidence is still connected.
-
-## What To Emphasize
-
-- It reduces the cognitive load of returning to an AI-assisted project after
-  days, weeks, or many different AI sessions.
-- It keeps AI-generated specs, plans, decisions, references, and routing rules
-  from becoming unmanaged clutter.
-- It separates central governance rules from project-local truth.
-- It has two practical profiles: engineering-runtime and doc-only.
-- It provides `doc-gov` commands for schema checks, manifest freshness, link
-  checks, router integrity, health checks, and read-only migration checks.
-- It provides `pro-gov` commands for packaged starter/profile assets,
-  read-only init planning, read-only sync checks, and package health checks.
-- It includes ProjectLens-style read-only inspection and a governed local agent
-  asset registry without publishing private or third-party skill bodies.
-- It works with external workflow systems instead of replacing them:
-  Superpowers owns engineering process, while Ponytail may act as an optional
-  complexity adviser with global mode `off`.
-
-## Do Not Overclaim
-
-- Do not say it replaces Git.
-- Do not say it replaces Superpowers.
-- Do not say it requires or automatically enables Ponytail.
-- Do not promise a fixed percentage reduction in code, tokens, time, or cost.
-- Do not say it automatically migrates every project.
-- Do not imply product prompts, generated media, or runtime assets must move
-  under `docs/**`.
-
-## Suggested Website Prompt
-
-```text
-Read <local ProjectGovernanceSystem checkout path> as the source project.
-
-Add Project Governance System to <local PieAIStudio-Site path> as a
-public project surface. Follow the existing project-page pattern, homepage card
-pattern, translations, and sitemap conventions in that website repository.
-
-Use the central repo's README.md, packages/doc-gov/README.md,
-packages/pro-gov/README.md, docs/reference/adoption/public-release-checklist.md,
-and docs/reference/adoption/site-publication-brief.md as source material.
-
-Position it for normal readers as the system that keeps long-running AI-assisted
-projects understandable and governable. Lead with the pain: AI creates useful
-plans, specs, rules, and evidence faster than people can organize and retire
-them. Use the librarian, traffic desk, and inspection-machine analogy before
-technical package details. Explain how it fits next to Git, AGENTS.md,
-Superpowers, optional Ponytail advice, pro-gov starter/profile distribution,
-ProjectLens inspection, and project-local product truth.
-
-Keep the copy confident but accurate. Do not claim automatic migration or
-full replacement of existing workflow tools. npm publication is live, so include
-the package install commands for @pieai/doc-gov and @pieai/pro-gov, and link the
-npm packages plus the GitHub repository.
-
-After implementation, run the site's normal quality/typecheck/build checks and
-verify the new public route plus sitemap entry.
-```