feat: orchestration harness, selective install, observer improvements

docs/PHASE1-ISSUE-BUNDLE-2026-03-12.md

@@ -0,0 +1,272 @@
+# Phase 1 Issue Bundle — March 12, 2026
+
+## Status
+
+These issue drafts were prepared from the March 11 mega plan plus the March 12
+handoff. I attempted to open them directly in GitHub, but issue creation was
+blocked by missing GitHub authentication in the MCP session.
+
+## GitHub Status
+
+These drafts were later posted via `gh`:
+
+- `#423` Implement manifest-driven selective install profiles for ECC
+- `#421` Add ECC install-state plus uninstall / doctor / repair lifecycle
+- `#424` Define canonical session adapter contract for ECC 2.0 control plane
+- `#422` Define generated skill placement and provenance policy
+- `#425` Define governance and visibility past the tool call
+
+The bodies below are preserved as the local source bundle used to create the
+issues.
+
+## Issue 1
+
+### Title
+
+Implement manifest-driven selective install profiles for ECC
+
+### Labels
+
+- `enhancement`
+
+### Body
+
+```md
+## Problem
+
+ECC still installs primarily by target and language. The repo now has first-pass
+selective-install manifests and a non-mutating plan resolver, but the installer
+itself does not yet consume those profiles.
+
+Current groundwork already landed in-repo:
+
+- `manifests/install-modules.json`
+- `manifests/install-profiles.json`
+- `scripts/ci/validate-install-manifests.js`
+- `scripts/lib/install-manifests.js`
+- `scripts/install-plan.js`
+
+That means the missing step is no longer design discovery. The missing step is
+execution: wire profile/module resolution into the actual install flow while
+preserving backward compatibility.
+
+## Scope
+
+Implement manifest-driven install execution for current ECC targets:
+
+- `claude`
+- `cursor`
+- `antigravity`
+
+Add first-pass support for:
+
+- `ecc-install --profile <name>`
+- `ecc-install --modules <id,id,...>`
+- target-aware filtering based on module target support
+- backward-compatible legacy language installs during rollout
+
+## Non-Goals
+
+- Full uninstall/doctor/repair lifecycle in the same issue
+- Codex/OpenCode install targets in the first pass if that blocks rollout
+- Reorganizing the repository into separate published packages
+
+## Acceptance Criteria
+
+- `install.sh` can resolve and install a named profile
+- `install.sh` can resolve explicit module IDs
+- Unsupported modules for a target are skipped or rejected deterministically
+- Legacy language-based install mode still works
+- Tests cover profile resolution and installer behavior
+- Docs explain the new preferred profile/module install path
+```
+
+## Issue 2
+
+### Title
+
+Add ECC install-state plus uninstall / doctor / repair lifecycle
+
+### Labels
+
+- `enhancement`
+
+### Body
+
+```md
+## Problem
+
+ECC has no canonical installed-state record. That makes uninstall, repair, and
+post-install inspection nondeterministic.
+
+Today the repo can classify installable content, but it still cannot reliably
+answer:
+
+- what profile/modules were installed
+- what target they were installed into
+- what paths ECC owns
+- how to remove or repair only ECC-managed files
+
+Without install-state, lifecycle commands are guesswork.
+
+## Scope
+
+Introduce a durable install-state contract and the first lifecycle commands:
+
+- `ecc list-installed`
+- `ecc uninstall`
+- `ecc doctor`
+- `ecc repair`
+
+Suggested state locations:
+
+- Claude: `~/.claude/ecc/install-state.json`
+- Cursor: `./.cursor/ecc-install-state.json`
+- Antigravity: `./.agent/ecc-install-state.json`
+
+The state file should capture at minimum:
+
+- installed version
+- timestamp
+- target
+- profile
+- resolved modules
+- copied/managed paths
+- source repo version or package version
+
+## Non-Goals
+
+- Rebuilding the installer architecture from scratch
+- Full remote/cloud control-plane functionality
+- Target support expansion beyond the current local installers unless it falls
+  out naturally
+
+## Acceptance Criteria
+
+- Successful installs write install-state deterministically
+- `list-installed` reports target/profile/modules/version cleanly
+- `doctor` reports missing or drifted managed paths
+- `repair` restores missing managed files from recorded install-state
+- `uninstall` removes only ECC-managed files and leaves unrelated local files
+  alone
+- Tests cover install-state creation and lifecycle behavior
+```
+
+## Issue 3
+
+### Title
+
+Define canonical session adapter contract for ECC 2.0 control plane
+
+### Labels
+
+- `enhancement`
+
+### Body
+
+```md
+## Problem
+
+ECC now has real orchestration/session substrate, but it is still
+implementation-specific.
+
+Current state:
+
+- tmux/worktree orchestration exists
+- machine-readable session snapshots exist
+- Claude local session-history commands exist
+
+What does not exist yet is a harness-neutral adapter boundary that can normalize
+session/task state across:
+
+- tmux-orchestrated workers
+- plain Claude sessions
+- Codex worktrees
+- OpenCode sessions
+- later remote or GitHub-integrated operator surfaces
+
+Without that adapter contract, any future ECC 2.0 operator shell will be forced
+to read tmux-specific and markdown-coordination details directly.
+
+## Scope
+
+Define and implement the first-pass canonical session adapter layer.
+
+Suggested deliverables:
+
+- adapter registry
+- canonical session snapshot schema
+- `dmux-tmux` adapter backed by current orchestration code
+- `claude-history` adapter backed by current session history utilities
+- read-only inspection CLI for canonical session snapshots
+
+## Non-Goals
+
+- Full ECC 2.0 UI in the same issue
+- Monetization/GitHub App implementation
+- Remote multi-user control plane
+
+## Acceptance Criteria
+
+- There is a documented canonical snapshot contract
+- Current tmux orchestration snapshot code is wrapped as an adapter rather than
+  the top-level product contract
+- A second non-tmux adapter exists to prove the abstraction is real
+- Tests cover adapter selection and normalized snapshot output
+- The design clearly separates adapter concerns from orchestration and UI
+  concerns
+```
+
+## Issue 4
+
+### Title
+
+Define generated skill placement and provenance policy
+
+### Labels
+
+- `enhancement`
+
+### Body
+
+```md
+## Problem
+
+ECC now has a large and growing skill surface, but generated/imported/learned
+skills do not yet have a clear long-term placement and provenance policy.
+
+This creates several problems:
+
+- unclear separation between curated skills and generated/learned skills
+- validator noise around directories that may or may not exist locally
+- weak provenance for imported or machine-generated skill content
+- uncertainty about where future automated learning outputs should live
+
+As ECC grows, the repo needs explicit rules for where generated skill artifacts
+belong and how they are identified.
+
+## Scope
+
+Define a repo-wide policy for:
+
+- curated vs generated vs imported skill placement
+- provenance metadata requirements
+- validator behavior for optional/generated skill directories
+- whether generated skills are shipped, ignored, or materialized during
+  install/build steps
+
+## Non-Goals
+
+- Building a full external skill marketplace
+- Rewriting all existing skill content in one pass
+- Solving every content-quality issue in the same issue
+
+## Acceptance Criteria
+
+- A documented placement policy exists for generated/imported skills
+- Provenance requirements are explicit
+- Validators no longer produce ambiguous behavior around optional/generated
+  skill locations
+- The policy clearly states what is publishable vs local-only
+- Follow-on implementation work is split into concrete, bounded PR-sized steps
+```