@pieai/pro-gov 0.3.6 → 0.3.8

package/README.md

@@ -11,6 +11,7 @@ station:
 - `pro-gov` shows which reusable project-governance parts are present or missing;
 - `@pieai/doc-gov` checks documents, routing, links, hooks, and CI;
 - Superpowers may provide the engineering process;
+- Compound Engineering may provide the post-work learning capture tail;
 - Ponytail may provide an optional simplicity review.
 
 The current `pro-gov` release is conservative by design. Public init and sync
@@ -47,8 +48,9 @@ pro-gov portfolio plan --config /path/to/portfolio.json --target web-app --json
 pro-gov lens inspect --target .
 pro-gov lens report --target . --out .pro-gov/lens-report.md
 pro-gov init --profile engineering-runtime --dry-run
+pro-gov init --profile engineering-runtime --apply
 pro-gov init --profile doc-only --dry-run
-pro-gov sync --check
+pro-gov sync --check --profile engineering-runtime
 pro-gov doctor
 ```
 
@@ -59,18 +61,20 @@ What these commands do:
 | `assets list` | Shows packaged assets and public registry metadata. | No |
 | `assets discover` | Detects local project signals. | No |
 | `assets recommend` | Suggests relevant asset bundles with reasons. | No |
-| `portfolio check` | Validates an external portfolio manifest owned by the user's control repo. | No |
-| `portfolio plan` | Builds dry-run asset plans for manifest targets. | No |
+| `portfolio check` | Validates an external portfolio manifest owned by the user or organization. | No |
+| `portfolio plan` | Builds dry-run asset plans for manifest targets, using packaged public assets unless a full checkout is supplied. | No |
 | `lens inspect` | Produces ProjectLens-style local evidence. | No |
 | `lens report` | Writes the requested report file. | Only the explicit output |
 | `init --dry-run` | Shows starter/profile files that would be needed. | No |
-| `sync --check` | Compares local starter files with packaged assets. | No |
+| `init --apply` | Installs one profile into a fresh target; refuses the whole operation if any target file exists. Optional CI and Lefthook references are not installed. | Yes |
+| `sync --check` | Strictly compares shared core files and checks only the presence of project-local seed files. | No |
 | `doctor` | Checks required packaged assets and whether `doc-gov` is available. | No |
 
 ## Full Checkout Commands
 
-A full Project Governance System checkout may also manage Yuanfei's local
-agent-asset registry through reviewed plans:
+The npm package can install reviewed public agent assets through an explicit
+plan. A full Project Governance System checkout can additionally use its
+maintainer-local asset registry:
 
 ```bash
 pro-gov assets plan --bundle base-governance --target . --out .pro-gov/asset-plan.json
@@ -109,7 +113,9 @@ the private-source and public-copy hashes recorded during promotion.
   deterministic recommendations.
 - `pro-gov portfolio check|plan` reads an external portfolio manifest. Real
   downstream project lists belong in the user's control repository, not in this
-  public package.
+  public package. The manifest does not require a private headquarters repo:
+  npm users can omit `controlPlane` and `executionEngine`, and PGS will use the
+  reviewed public assets packaged with `@pieai/pro-gov`.
 - `pro-gov assets plan|apply|check` manages local assets only from an explicit,
   reviewable plan in a full upstream checkout.
 - `pro-gov lens inspect|report` provides read-only inspection and an explicit
@@ -117,14 +123,22 @@ the private-source and public-copy hashes recorded during promotion.
 - `doc-gov` remains the document, router, manifest, link, hook, CI, and migration
   validator.
 - Product truth stays in the target project.
-- Write-mode `pro-gov init --apply` is not enabled in this release.
-- Superpowers and Ponytail are external tools, not bundled runtime dependencies.
+- `pro-gov init --apply` is intentionally fresh-target only. Existing projects
+  use `--dry-run` and a deliberate migration so local truth is never overwritten.
+- Superpowers, Compound Engineering, and Ponytail are external tools, not
+  bundled runtime dependencies.
 
 ## Recommended Companion Tools
 
 Superpowers is recommended for engineering/runtime projects that need
 brainstorming, plans, TDD, debugging, verification, and worktree discipline.
 
+Compound Engineering is recommended for knowledge capture after verified
+engineering work. The default PGS pattern is a Compound Gate: run
+`ce-compound` when there is reusable learning, or report why compounding was
+skipped. Full CE workflows such as `ce-plan`, `ce-work`, and `lfg` remain
+explicit user choices.
+
 Ponytail can be installed as an optional complexity adviser. Keep its global mode
 `off`; test `lite` in one isolated task before considering a stronger mode.
 Ponytail must not remove requested scope, tests, safety, accessibility, or proof.

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

@@ -24,8 +24,9 @@ Use this when a project wants to migrate into the Project Governance System.
 
 Before choosing external AI workflow tools, read
 `docs/reference/adoption/recommended-agent-tooling.md`. It explains which PGS
-packages are required, when Superpowers is recommended, and why Ponytail should
-remain globally `off` until it is tested in an isolated task.
+packages are required, when Superpowers is recommended, how Compound
+Engineering's `ce-compound` fits as a post-work learning tail, and why Ponytail
+should remain globally `off` until it is tested in an isolated task.
 
 ## The Short Version
 
@@ -70,8 +71,15 @@ Current package-based method:
 - 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
+- for a fresh target, run `pro-gov init --profile <profile> --apply`; it refuses
+  the entire operation if any destination already exists
+- optional Lefthook and GitHub Actions guardrails remain reference assets; add
+  them deliberately when the target has the matching package manager and CI
+- for an existing target, keep the dry-run output as the migration checklist and
+  merge local truth deliberately instead of asking PGS to overwrite it
+- run `pro-gov sync --check --profile <profile>` to compare shared core files;
+  project-local router, policy, documentation map, and current-work files are
+  checked for presence rather than byte equality
 - run `pro-gov assets discover --target <path>` and
   `pro-gov assets recommend --target <path>` to collect local project signals
   and suggested agent-asset bundles without changing the project
@@ -89,14 +97,16 @@ Current package-based method:
 - 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
+pnpm pro-gov init --profile engineering-runtime --dry-run
+pnpm pro-gov init --profile engineering-runtime --apply
+pnpm doc-gov scan
+pnpm pro-gov sync --check --profile engineering-runtime
 ```
 
-Do not jump to write-mode installation until package installation is
-deliberately enabled and the read-only checks are understood.
+Use `--apply` only for a fresh target. Existing projects normally already own
+some of the same paths, so keep them on the dry-run migration path.
 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.
@@ -129,6 +139,12 @@ The plan file is the safety gate. Review it before applying. It creates managed
 symlinks and `.pro-gov/assets.lock.json`; it should not overwrite unmanaged
 project files.
 
+Managed symlinks are relative by default. A target project's normal
+`assets check` validates the local lock and linked content without requiring the
+public package to know a maintainer's private registry. Maintainers can add
+`--strict-registry`, or run `pro-gov portfolio assets-check --config
+/path/to/portfolio.json`, when they need central private-registry validation.
+
 When a maintainer promotes a private asset into `public-agent-assets/`, the
 public registry must record the private-source hash and the public-copy hash.
 Run this in the upstream checkout before publishing:
@@ -177,6 +193,11 @@ 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/`.
 
+For engineering projects, keep Superpowers as the default engineering workflow.
+Use Compound Engineering by default only as the post-work Compound Gate:
+`ce-compound` captures reusable lessons when they exist; otherwise the agent
+reports a skip reason. Full CE workflows require an explicit user request.
+
 ### Doc-Only
 
 Add:
@@ -188,6 +209,10 @@ Add:
 
 Do not add Superpowers TDD or Directed Development by default.
 
+Do not add the Compound Engineering main workflow by default. If CE is installed
+in the AI host, doc-only projects should use it only for a real reusable
+learning that belongs in that workspace.
+
 Ponytail is also optional. If it is installed, keep its global mode `off` and
 activate it only for a bounded task or review after reading
 `integrations/ponytail.md`.
@@ -251,7 +276,8 @@ If the target project is an app/runtime project:
 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.
+4. Preview the selected profile. Use fresh-target `init --apply`, or merge the
+   starter files deliberately when the project already has local truth.
 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/`.

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

@@ -22,7 +22,8 @@ related:
 
 This file answers the most important beginner question:
 
-> If Non-Heroes already has doc-gov, and this central repo now exists, who owns what?
+> If a project adopts PGS, which parts stay upstream and which parts belong to
+> that project?
 
 ## Short Answer
 
@@ -55,7 +56,7 @@ 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?
+## Does A Target Project Import This Whole Repository?
 
 Not yet automatically.
 
@@ -64,10 +65,10 @@ the user's external portfolio manifest. See
 `docs/reference/adoption/downstream-project-registry.md` for the public
 manifest contract.
 
-Early downstream projects 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.
+Early adopters may have local working copies because governance often starts
+inside an active project. The public packages are now the reusable source, and
+target 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?
 
@@ -91,21 +92,19 @@ projects need different local lane profiles. The safe rule:
 - 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
+## How Target-Project Improvements Flow Upstream
 
-When Non-Heroes discovers a better governance rule:
+When a target project discovers a better governance rule:
 
-1. Ask: is this core, profile, or Non-Heroes-local?
+1. Ask: is this core, profile, or target-local?
 2. If core, update this repo.
 3. If profile, update the relevant `profiles/**`.
-4. If Non-Heroes-local, keep it in Non-Heroes.
+4. If it is target-local, keep it in the target project.
 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.
+Example: one active project discovers that completed plans are piling up. If the
+generic fix is a reusable `completed` lifecycle state, that state belongs in the
+PGS core; the project's actual completed plans remain local.
 
 ## How Downstream Projects Upgrade
 

package/assets/docs/reference/adoption/recommended-agent-tooling.md

@@ -12,6 +12,7 @@ tags:
   - adoption
   - tooling
   - superpowers
+  - compound-engineering
   - ponytail
 pinned: false
 related:
@@ -30,6 +31,7 @@ Imagine a school workshop:
 
 - PGS labels the shelves, routes each job, and checks that the record is complete.
 - Superpowers gives the class a reliable build-and-test routine.
+- Compound Engineering keeps the class notebook of hard-won lessons.
 - Ponytail is the adviser who asks, "Can we make this with fewer unnecessary
   parts?"
 
@@ -42,6 +44,7 @@ Installing every tool does not mean every tool should run all the time.
 | `@pieai/pro-gov` | Required for package-based PGS adoption | Projects adopting PGS starter/profile assets | Use its read-only discovery, init, sync, doctor, and Lens commands. |
 | `@pieai/doc-gov` | Required for package-based PGS adoption | All governed PGS projects | Run document, router, manifest, link, hook, and CI checks. |
 | Superpowers | Recommended for engineering/runtime projects | Apps, games, services, browser products, and other code-heavy work | Use the matching workflow when the selected PGS lane requires it. |
+| Compound Engineering | Recommended for knowledge capture | Engineering projects that benefit from reusable learnings | Default to `ce-compound` as the post-work Compound Gate; use full CE workflows only when explicit. |
 | Ponytail | Recommended as an installed, optional adviser | Projects that need help resisting unnecessary complexity | Keep the global mode `off`; activate it explicitly for a bounded task or review. |
 
 ## Superpowers
@@ -63,6 +66,25 @@ task actually involves runtime or code behavior.
 
 Read `integrations/superpowers.md` for the exact boundary.
 
+## Compound Engineering
+
+Compound Engineering is useful for preserving lessons that should make future
+work easier. In PGS-governed projects, its default role is the post-work
+Compound Gate:
+
+```text
+Superpowers completes verified work
+-> decide with CE criteria whether reusable learning exists
+-> run ce-compound or report a skip reason
+```
+
+Do not make routine tasks choose between Superpowers and Compound Engineering as
+competing default engineering processes. Use CE's full `ce-plan`, `ce-work`, or
+`lfg` flow only when the user explicitly asks for it.
+
+Read `integrations/compound-engineering.md` for artifact ownership and Doc Gov
+compatibility.
+
 ## Ponytail
 
 Ponytail advises the AI to prefer smaller, less speculative solutions. That can
@@ -85,6 +107,7 @@ For an engineering/runtime project:
 ```text
 install PGS packages
 -> keep Superpowers available for engineering workflows
+-> use Compound Engineering's ce-compound as the post-work learning tail
 -> install Ponytail but keep global mode off
 -> activate Ponytail only when a bounded simplicity review would help
 ```
@@ -103,4 +126,3 @@ install PGS packages
 PGS does not automatically install, enable, update, or remove these external
 plugins in another person's AI host. It documents the recommended boundary and
 lets each project or user adopt tools deliberately.
-

package/assets/integrations/compound-engineering.md

@@ -0,0 +1,124 @@
+# Compound Engineering Integration
+
+Compound Engineering is an external plugin/system. This repository does not
+vendor, rewrite, or require the Compound Engineering plugin.
+
+## The Beginner Version
+
+Think of an AI project as a workshop:
+
+- PGS is the traffic desk and filing cabinet.
+- Superpowers is the default cooking process for engineering work.
+- Compound Engineering's `ce-compound` is the recipe notebook written after a
+  non-trivial dish is proven to work.
+- Ponytail is the cost and complexity adviser.
+
+The default path is one main process with one learning tail. Do not make every
+task choose between two construction processes.
+
+## Default Rule
+
+For PGS-governed engineering/runtime projects, Superpowers remains the default
+engineering workflow. Compound Engineering is installed for its knowledge
+capture loop by default, not as a second default execution engine.
+
+Use this order:
+
+1. PGS routes the task and selects the project lane.
+2. Superpowers handles the normal engineering workflow when that lane needs one.
+3. Ponytail may run as an explicit complexity review when useful.
+4. The agent must pass the Compound Gate before final reporting.
+5. Doc Gov validates governed documentation and ignores CE-owned external
+   artifacts.
+
+## Compound Gate
+
+Every completed non-trivial engineering task must pass the Compound Gate:
+
+```text
+Was there reusable learning?
+-> yes: run compound-engineering:ce-compound
+-> no: report "Compound Gate: skipped" and give the reason
+```
+
+Use Compound Engineering's own capture criteria. Do not invent a separate PGS
+scoring system.
+
+Run `ce-compound` when the completed work produced a reusable lesson, such as:
+
+- a non-obvious bug diagnosis;
+- a repeated pattern or root cause;
+- a wrong assumption about a shared dependency, framework, convention, or tool;
+- a new reusable architecture, workflow, verification, or tooling pattern;
+- owner intent that the lesson should be remembered.
+
+Skip compounding when the work was:
+
+- unverified or still in progress;
+- a trivial typo or obvious one-line fix;
+- mechanical formatting, dependency bumping, or bulk sync work;
+- already covered by an existing `docs/solutions/**` learning.
+
+The skip must be explicit in the final report. This prevents agents from
+forgetting the gate while avoiding a low-value knowledge dump.
+
+## When CE May Own The Main Flow
+
+Use the full Compound Engineering flow only when the user explicitly names it,
+for example `ce-plan`, `ce-work`, `lfg`, or "use Compound Engineering full
+workflow."
+
+Do not auto-select between Superpowers and Compound Engineering for routine
+work. Automatic choice adds cognitive load and makes sessions harder to reason
+about.
+
+## CE-Owned Artifacts
+
+The following paths are Compound Engineering external artifacts:
+
+| Path | Owner | Rule |
+| --- | --- | --- |
+| `docs/solutions/**` | CE | Knowledge store written by `ce-compound`; uses CE frontmatter. |
+| `docs/brainstorms/**` | CE | CE brainstorm artifacts; explicit CE use only. |
+| `docs/pulse-reports/**` | CE | CE product-pulse reports; explicit CE use only. |
+| `docs/plans/*` | CE | CE-native root plan artifacts; explicit CE full workflow only. |
+
+PGS-owned plans remain:
+
+```text
+docs/plans/active/**
+docs/plans/completed/**
+```
+
+Doc Gov must not require CE-owned artifacts to use PGS frontmatter. The
+directory decides which schema applies:
+
+```text
+docs/solutions/** and other CE-owned paths -> CE schema
+PGS governed docs -> Doc Gov schema
+```
+
+Do not try to make one YAML block satisfy both systems.
+
+## Root Files
+
+Compound Engineering may read project root files when present, but PGS-governed
+projects keep these boundaries:
+
+| File | Rule |
+| --- | --- |
+| `STRATEGY.md` | CE must not create or overwrite this by default in PGS-governed projects. Product strategy belongs in the project's canon/control plane unless explicitly adopted. |
+| `CONCEPTS.md` | Allowed as a CE vocabulary helper, but it does not replace `docs/canon/**` or project runtime truth. |
+| `AGENTS.md` / `CLAUDE.md` | CE discoverability edits must stay short and must not replace the PGS router. |
+| `.compound-engineering/config.local.yaml` | Machine-local CE config; keep gitignored. |
+
+## Completion Report
+
+When a task finishes, report one of:
+
+```text
+Compound Gate: ran ce-compound -> docs/solutions/<category>/<file>.md
+Compound Gate: skipped -> <reason>
+```
+
+This is the durable signal that the learning tail was considered.

package/assets/integrations/ponytail.md

@@ -107,3 +107,55 @@ flowchart TD
 For normal engineering, Ponytail is a scoped adviser, not a second workflow
 engine and not a replacement for Superpowers.
 
+## ProjectLens Audit Use
+
+When ProjectLens and Ponytail are used together for a target-project audit,
+ProjectLens owns the audit package contract. Ponytail acts as an independent
+senior engineering reviewer whose simplicity, YAGNI, dependency, abstraction,
+and rewrite judgment can challenge ProjectLens recommendations.
+
+For this combined workflow, "read-only project audit" means the target
+repository must not be modified. It does not mean "do not write the PGS audit
+package." The audit package is the required owner-facing evidence record.
+
+Use this order:
+
+1. The main agent establishes target path, goal, current phase, target commit or
+   working state, then creates the package with
+   `pro-gov lens audit init --target <path> --out audits/<target>/<date>`.
+2. ProjectLens gathers local evidence and writes its own raw artifacts under
+   `raw/project-lens/`.
+3. Ponytail runs independently and writes its own raw artifacts under
+   `raw/ponytail/`. For initial whole-project audits, preserve at least
+   `ponytail-audit`, `ponytail-debt`, and `ponytail-gain` outputs when the
+   plugin can produce them.
+4. The target command log records Project Lens and Ponytail method sources.
+5. The main agent writes `synthesis/decision-index.md` and
+   `synthesis/handoff-for-implementation-ai.md`, then runs
+   `pro-gov lens audit check --dir audits/<target>/<date>`.
+
+Use subagents for the ProjectLens/Ponytail raw passes when the AI host exposes
+them and the user has authorized subagent or parallel agent work. If host rules
+block subagents, preserve the same raw-output separation with serial passes and
+record the fallback in the audit package. Do not claim that subagents were used
+when they were not. The manifest must include `Subagent trace:` with each pass
+role, execution mode, final status, and raw artifact path; if durable subagent
+IDs are unavailable, record that limitation.
+
+Do not blur a fresh audit with a reuse verification. For a fresh ProjectLens plus
+Ponytail audit, run `pro-gov lens audit check --dir <audit-dir> --mode fresh`.
+If an existing package is reused because the target commit and package check are
+still valid, label the result as reuse and run `--mode reuse`.
+
+Do not blend Ponytail findings into ProjectLens files. Do not suppress Ponytail
+to make ProjectLens look correct. Preserve material disagreements in the raw
+artifacts and let the synthesis state which judgment won and why. The shared
+boundary is evidence, user intent, project safety, explicit product-line
+direction, and PGS's technology-governance protocol. If a stack direction
+exists, Ponytail may challenge migration scope, timing, and complexity, while
+ProjectLens records the direction as the product group's stated intent and PGS
+classifies the execution posture.
+
+Use `ponytail-review` later for implementation diffs or PR-style changes. For
+initial read-only project audits, prefer the whole-repo Ponytail modes above so
+the audit starts from system shape instead of line-level patch review.

package/assets/integrations/superpowers.md

@@ -8,11 +8,13 @@ Think of an AI project as a building site:
 
 - PGS is the traffic desk and inspection station.
 - Superpowers is the construction process.
+- Compound Engineering's `ce-compound` is the knowledge-capture tail.
 - Ponytail is an optional cost and complexity adviser.
 
 PGS chooses the lane. Superpowers makes sure the work follows the right
-engineering process. Ponytail may suggest a leaner implementation, but it
-cannot cancel the process or the final inspection.
+engineering process. Compound Engineering records reusable lessons after
+verified work. Ponytail may suggest a leaner implementation, but it cannot
+cancel the process or the final inspection.
 
 ## Boundary
 
@@ -39,6 +41,12 @@ Ponytail, when explicitly enabled for a task, may advise on:
 - avoidable files and abstractions;
 - simpler implementation choices.
 
+Compound Engineering, by default, owns:
+
+- post-work knowledge capture through `ce-compound`;
+- `docs/solutions/**` learning records and their CE frontmatter;
+- CE-owned external artifacts when the user explicitly invokes CE workflows.
+
 ## Rule
 
 Use Superpowers inside the selected project lane. Do not let Superpowers create a separate durable document tree unless the project explicitly adopts one.
@@ -52,9 +60,10 @@ Durable outputs should map back to the project's doc-gov layers:
 ## Execution Order
 
 Agents routing classifies first. Superpowers executes inside the selected lane.
-Optional Ponytail advice comes after those responsibilities are known. It may
+Optional Ponytail advice may run after those responsibilities are known. It may
 make the implementation leaner, but it must not remove explicit requirements or
-reduce how correctness is proven.
+reduce how correctness is proven. The Compound Gate runs near the end, before
+final reporting, to decide whether verified work produced reusable learning.
 
 ```mermaid
 flowchart TD
@@ -64,10 +73,11 @@ flowchart TD
   D -- "yes" --> E["Use the matching Superpowers skill"]
   D -- "no" --> F["Use the local non-Superpowers lane rules"]
   E --> G{"Would an explicit simplicity review help?"}
-  F --> H["Write durable outputs into doc-gov layers"]
-  G -- "yes" --> I["Use Ponytail without dropping workflow gates"]
-  G -- "no" --> H
-  I --> H
+  F --> G
+  G -- "yes" --> H["Use Ponytail without dropping workflow gates"]
+  G -- "no" --> I["Pass the Compound Gate"]
+  H --> I
+  I --> J["Write durable outputs into doc-gov layers"]
 ```
 
 If Superpowers suggests a default location such as `docs/superpowers/**`, project instructions may override that location. The durable project record should still land in the governed doc-gov layer unless the project has explicitly adopted a separate Superpowers document tree.
@@ -78,3 +88,6 @@ router or run before the Project Governance System routing block.
 
 For Ponytail mode policy and the isolated comparison protocol, read
 `integrations/ponytail.md`.
+
+For Compound Engineering's knowledge-capture boundary, read
+`integrations/compound-engineering.md`.

package/assets/profiles/doc-only/manifest.yml

@@ -9,6 +9,7 @@ required:
   agents_routing: docs/governance/agents-routing/doc-only-v0.9.md
   current_work: docs/reference/execution/current-work.md
 optional:
+  compound_engineering: false
   directed_development: false
   superpowers: false
 project_local_required:
@@ -19,3 +20,4 @@ not_included:
   - engineering-runtime agents routing
   - behavior-critical code lanes
   - Superpowers TDD workflow
+  - Compound Engineering main workflow

package/assets/profiles/doc-only/profile.md

@@ -31,7 +31,7 @@ Each project must define:
 ## Automation Boundary
 
 This profile is a human/AI adoption contract. `doc-gov` validates the resulting
-project shape. `pro-gov` packages reusable starter/profile assets and exposes
-read-only init/sync checks, but it does not overwrite project-local files in
-the first release. Use `starter/`, this profile, and `manifest.yml` as the
-reference checklist.
+project shape. `pro-gov init --apply` can install it into a fresh target, but
+refuses all writes when any destination already exists. `sync --check` compares
+shared core files while leaving project-local router, policy, and current-work
+content under the target project's ownership.

package/assets/profiles/engineering-runtime/manifest.yml

@@ -9,6 +9,7 @@ required:
   agents_routing: docs/governance/agents-routing/engineering-runtime-v0.9.md
   current_work: docs/reference/execution/current-work.md
 optional:
+  compound_engineering: integrations/compound-engineering.md
   directed_development: integrations/directed-development.md
   superpowers: integrations/superpowers.md
 project_local_required:
@@ -20,3 +21,4 @@ not_included:
   - product canon
   - project-specific runtime rules
   - Superpowers plugin body
+  - Compound Engineering plugin body

package/assets/profiles/engineering-runtime/profile.md

@@ -10,6 +10,7 @@ Use for code-heavy projects: apps, games, runtimes, services, browser products,
 - external AI-in-the-Loop policy linked by target projects under `docs/policy/shared-rules/ai-in-the-loop.md`
 - `docs/governance/agents-routing/engineering-runtime-v0.9.md`
 - `integrations/superpowers.md`
+- `integrations/compound-engineering.md`
 - `integrations/directed-development.md`
 - starter `docs/governance/` and `docs/policy/` templates
 
@@ -29,11 +30,12 @@ Each project must define:
 - stack-specific rules
 - game/app-specific lane wording
 - Superpowers plugin body
+- Compound Engineering plugin body
 
 ## Automation Boundary
 
 This profile is a human/AI adoption contract. `doc-gov` validates the resulting
-project shape. `pro-gov` packages reusable starter/profile assets and exposes
-read-only init/sync checks, but it does not overwrite project-local files in
-the first release. Use `starter/`, this profile, and `manifest.yml` as the
-reference checklist.
+project shape. `pro-gov init --apply` can install it into a fresh target, but
+refuses all writes when any destination already exists. `sync --check` compares
+shared core files while leaving project-local router, policy, and current-work
+content under the target project's ownership.

package/assets/starter/AGENTS.template.md

@@ -37,7 +37,8 @@
 
 - Name this project's adopted profile: `engineering-runtime` or `doc-only`.
 - Point to the chosen agents-routing file from `docs/governance/agents-routing/`.
-- Engineering projects may use Superpowers, Directed Development, GStack, or other external workflows only inside the selected lane; do not copy upstream `integrations/` into the target project by default.
+- Engineering projects may use Superpowers, Directed Development, GStack, or other external workflows only inside the selected lane; do not copy upstream integration guides into the target project by default.
+- For engineering projects, Superpowers is the default engineering workflow. Compound Engineering is used by default only as the post-work Compound Gate through `ce-compound`; full CE workflows require an explicit user request.
 - Doc-only projects should say that Superpowers TDD and Directed Development are not enabled by default.
 - External workflow systems such as Superpowers or GStack run inside the lane selected by this router. They must not replace this project router.
 

package/assets/starter/docs/governance/boundary.md

@@ -46,6 +46,7 @@ project-specific AI development habits live.
 - Product prompts, generated media notes, or project-package workbench files.
 - Current project plans or active specs.
 - Superpowers plugin content.
+- Compound Engineering plugin content.
 
 ## Put Those Elsewhere
 
@@ -59,6 +60,7 @@ project-specific AI development habits live.
 | Product or world truth | `docs/canon/` |
 | Active implementation work | `docs/plans/active/` |
 | Completed proof records | `docs/plans/completed/` |
+| Compound Engineering learnings | `docs/solutions/**` as CE-owned external artifacts |
 | Product artifacts outside governed docs | Project package, workbench, assets, runtime config, or source tree |
 
 When unsure, ask this question: is this rule about how the document system works,
@@ -74,3 +76,8 @@ It does not govern every Markdown file in the repository. Markdown under
 product packages, workbenches, prompt libraries, source folders, or asset
 folders can be product artifacts. Keep those files where the product package
 expects them unless a project explicitly opts them into doc-gov.
+
+Compound Engineering external artifacts under `docs/solutions/**`,
+`docs/brainstorms/**`, `docs/pulse-reports/**`, and CE-native root files under
+`docs/plans/*` are not governed docs by default. They remain valid project
+artifacts, but their frontmatter belongs to Compound Engineering, not Doc Gov.