# Project Context

## Concept

`pi-feature-symbiont` packages the Feature Symbiont Skill (FSS) as one globally discoverable symbiogenesis protocol. The extension runtime owns only source-checkout skill discovery; the portable protocol creates and gardens project-local FSS instances.

## Boundaries

- The runtime registers the co-located `skills/` directory and owns no project mutation or delivery policy.
- The portable FSS protocol creates and gardens project-local feature symbionts while ordinary project work is already active.
- `<repo>/.agents/skills/settings.json` and `settings.toml` share one opt-out contract: top-level `fss` boolean `false` or exact string `"false"` disables all repository FSS activity, disabling wins across files, malformed settings fail closed, and disabled FSS files remain untouched.
- An FSS is one continuous `<feature>-delivery` support skill whose name and identity remain stable; `fss: true` is its sufficient FSS marker, no FSS-specific `type` is required, and root frontmatter `status` is its sole lifecycle property (`draft`, `stable`, or temporarily `deprecated`).
- A local FSS couples to canonical host work, documentation, validation, and knowledge surfaces; it grows local structure only for missing functions and runs apoptosis when verified host self-sufficiency makes its transient redundancy confidence at least `0.9`.
- The root FSS `SKILL.md` is both its operating protocol and its meta-index control plane: it keeps the always-needed kernel and routes conditional open-work, knowledge, and OKF detail through relative references.
- A knowledge bundle targets the latest published OKF specification when created or materially updated, and grows only when feature reasoning would otherwise be repeatedly reconstructed or overload `SKILL.md`.
- Every FSS-authored Markdown concept conforms to OKF; FSS-specific routing metadata extends the portable core under `fss`.
- One knowledge concept owns one responsibility; standard Markdown domain links are primary and OKF sources anchor evidence.
- Typed knowledge directories live directly under the feature-skill root; never add a redundant generic `concepts/` layer.
- `SKILL.md` plus source concepts are canonical; generated indexes are disposable projections.
- Documentation ownership is inferred independently of FSS status: actively maintained host documentation wins; otherwise the FSS grows local OKF knowledge.
- Ownership transitions migrate durable truth and remove the obsolete writable corpus instead of preserving host and FSS shadow documentation.
- FSS symbiogenesis remains a contextual protocol lens, never a workflow state machine, mode enum, transition table, or runtime concern; apoptosis confidence is computed from current evidence and never persisted as lifecycle state.
- An FSS owns the feature-support lens and delivery feedback when needed, not the feature's code, specification, history, scheduler, or external authority.
- Existing project plans, issue trackers, and backlogs remain canonical when suitable.
- An FSS with active delivery work may create a co-located `BACKLOG.md` only when its feature has no suitable canonical open-work surface; a `status: stable` knowledge-and-support symbiont omits stale task routing.
- Skills compose through neutral declarations such as `Canonical open work: <path>` rather than naming sibling skills or execution protocols.
- Durable rules belong here, open work in `BACKLOG.md`, completed delivery in `CHANGELOG.md`, and operator-facing usage in `README.md`.

## Topology

```text
index.ts                           source-checkout skill registration
skills/feature-symbiont/SKILL.md   compact symbiogenesis kernel and router
skills/feature-symbiont/references conditional work, knowledge, and OKF contracts
README.md                          human entrypoint
BACKLOG.md                         unresolved package work
CHANGELOG.md                       completed package delivery
```

## Style

- Keep the runtime minimal and side-effect free beyond resource discovery.
- Keep FSS portable and free of hard-coded sibling skill dependencies.
- Keep always-needed opt-out, safety, and lifecycle rules in root `SKILL.md`; move concern-specific detail behind explicit relative-path triggers.
- Prefer one canonical work surface per feature scope.
- Keep mutable task state outside `SKILL.md`.
- Keep the knowledge corpus outside `SKILL.md`; retain only its access and lifecycle protocol there.
- Keep authority, retrieval, maintenance, and verification priorities independent from each other and from product priority.
- Prefer living host documentation over local knowledge convenience; create local OKF concepts only when the feature has no established documentation path.