Add PR template, CODEOWNERS, and three issue templates (#6)

Closes the loop on the contribution flow CONTRIBUTING.md describes.

(a) .github/PULL_REQUEST_TEMPLATE.md: bakes the four pieces
CONTRIBUTING.md asks for — linked issue, ADR reference, local
make kb-eval-outcomes result, pre-merge checklist. The kb-gate: ack
escape hatch is documented in an HTML comment but the literal
ack-marker string is intentionally NOT in the template (so the
Phase 2A gate doesn't false-positive on every PR).

(b) .github/CODEOWNERS: auto-requests @bb-connor review on changes to
load-bearing surfaces — PLAN/AGENTS/CLAUDE/CONTRIBUTING/README/LICENSE,
decisions/, chio-pack/eval/, kb-engine/, chio-pack-{pyproject.toml,
__init__.py}, .github/, Makefile, chio-pr-gate/, infra/, .env.example.
Vault content (spec/, episodes/, playbooks/, daily/, _meta/queries/)
is intentionally NOT covered — auto-requesting review on every typo
fix is noise.

(c) .github/ISSUE_TEMPLATE/{bug-report,feature-request,adr-proposal}.md:
match CONTRIBUTING's "open an issue first" advice. Bug template asks
for kb-status output and reminds the user to check Phase awareness.
Feature template asks for the phase mapping and whether an ADR is
required. ADR template mirrors decisions/ADR-NNNN structure (context,
decision, consequences, alternatives) and tells the user to file the
real ADR at decisions/ADR-NNNN-title.md after the issue converges.

(d) is this PR itself: opened as a draft to verify the eval workflow's
PR-comment path actually fires. The eval-outcomes table should appear
as an automated comment below shortly after CI completes.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: bb-connor

.github/CODEOWNERS

@@ -0,0 +1,48 @@
+# CODEOWNERS — auto-request reviewers on PRs touching specific paths.
+#
+# Format:    <pattern>     <reviewer1> [reviewer2 ...]
+# Last-matching pattern per file wins.
+# Patterns use gitignore-style globs (with leading slash anchoring to repo root).
+#
+# Docs: https://docs.github.com/en/repositories/managing-your-repositories-settings-and-customizations/customizing-your-repository/about-code-owners
+
+# === Load-bearing top-level docs ===
+# Anything that defines the project's contract.
+/PLAN.md            @bb-connor
+/AGENTS.md          @bb-connor
+/CLAUDE.md          @bb-connor
+/CONTRIBUTING.md    @bb-connor
+/README.md          @bb-connor
+/LICENSE            @bb-connor
+
+# === ADRs — every decision deserves review ===
+/decisions/         @bb-connor
+
+# === Eval surface — outcome targets, rubrics, raters, runner ===
+# Changing what "the carve-out works" means is an ADR-level decision.
+/chio-pack/eval/                    @bb-connor
+/chio-pack/chio_pack/eval/          @bb-connor
+
+# === Engine ↔ pack boundary ===
+# kb-engine cannot import chio_*. The boundary is enforced by CI (Phase 1+).
+# Changes to either side require explicit review.
+/kb-engine/                         @bb-connor
+/chio-pack/pyproject.toml           @bb-connor
+/chio-pack/chio_pack/__init__.py    @bb-connor
+
+# === CI / repo plumbing ===
+/.github/                           @bb-connor
+/Makefile                           @bb-connor
+/.gitignore                         @bb-connor
+
+# === Phase 2 surfaces (placeholders today; moonshot deliverables) ===
+/chio-pr-gate/                      @bb-connor
+
+# === Infrastructure config ===
+/infra/                             @bb-connor
+/.env.example                       @bb-connor
+
+# Note: most vault content (spec/, episodes/, playbooks/, daily/, _meta/queries/)
+# is intentionally NOT in CODEOWNERS. Vault content evolves rapidly and
+# auto-requesting review on every typo fix is noise. Reviewers will be
+# tagged manually when material vault changes are proposed.

.github/ISSUE_TEMPLATE/adr-proposal.md

@@ -0,0 +1,46 @@
+---
+name: ADR proposal
+about: Propose a new architecture decision record
+title: "[adr] "
+labels: ["enhancement"]
+---
+
+## Context
+
+<!-- What's true today and what changed that triggered this ADR? -->
+
+## Proposed decision
+
+<!-- What we'd choose. State the rule, not the rationale. Be specific. -->
+
+## Consequences
+
+**Positive**
+
+- 
+
+**Negative**
+
+- 
+
+## Alternatives considered
+
+- **Alternative A.** Description. Why rejected.
+- 
+
+## Affected files / surfaces
+
+<!-- Which parts of the repo would this change touch? -->
+
+## Phase
+
+<!-- Which phase, if any, depends on this ADR being Accepted? -->
+
+---
+
+<!--
+After this issue is reviewed and the direction is clear, file the actual ADR
+at `decisions/ADR-NNNN-title.md` per the template at
+`vault/_meta/templates/adr.md`. Then close this issue with a link to the
+filed ADR.
+-->

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,40 @@
+---
+name: Bug report
+about: Report a bug in chio-developer-base
+title: "[bug] "
+labels: ["bug"]
+---
+
+## What happened
+
+<!-- One-sentence description. -->
+
+## Steps to reproduce
+
+1. 
+2. 
+3. 
+
+## Expected
+
+<!-- What should have happened. -->
+
+## Actual
+
+<!-- What did happen. Include error output, stack traces, or `make kb-eval-outcomes` differences. -->
+
+## Environment
+
+- OS:
+- `make kb-status` output:
+
+```
+```
+
+## Phase awareness
+
+<!--
+If this bug is about a Phase 1+ feature that hasn't landed yet (e.g.,
+`make kb-up` failing), that's not a bug — it's a not-yet-implemented
+item. See PLAN.md "Phased delivery" before filing.
+-->

.github/ISSUE_TEMPLATE/feature-request.md

@@ -0,0 +1,42 @@
+---
+name: Feature request
+about: Propose a new feature or enhancement
+title: "[feature] "
+labels: ["enhancement"]
+---
+
+## What
+
+<!-- One sentence on what you want. -->
+
+## Why
+
+<!-- The pain point this solves. Be specific — "easier" is not specific. -->
+
+## Phase
+
+<!--
+Which phase does this belong to (per PLAN.md)?
+Phase 0 / 1 / 2A / 2B / 3 / 4, or "outside the current plan".
+
+If outside: how does it relate to the existing scope? Should it become
+its own phase or fold into an existing one?
+-->
+
+## ADR required?
+
+<!--
+Most new features that affect:
+- The vault folder layout
+- The engine ↔ pack boundary
+- The MCP tool set
+- Outcome-eval targets
+
+require an ADR before implementation. If yes, sketch the ADR's
+Decision section here so the discussion can converge before someone
+writes code. If no, briefly justify.
+-->
+
+## Acceptance
+
+<!-- How will we know this is done? Specific, testable, ideally an eval target. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,45 @@
+## Summary
+
+<!-- 1-2 sentences. What changed and why. -->
+
+## Linked issue
+
+<!-- "Closes #NNN" or "Fixes #NNN" — required for non-trivial changes. If no issue: explain why none was filed. -->
+
+## ADRs
+
+<!--
+Required if this change:
+- Adds a top-level vault folder
+- Modifies the Obsidian plugin allowlist
+- Touches the engine ↔ pack boundary
+- Adjusts outcome-eval targets
+- Otherwise affects load-bearing infrastructure (see CONTRIBUTING.md)
+
+Write "None — change is not load-bearing" or "Requires ADR-NNNN-name".
+-->
+
+## Eval result
+
+<!-- Output of `make kb-eval-outcomes` from your local checkout. Paste the table below or the summary line if non-blocked. -->
+
+```
+```
+
+## Pre-merge checklist
+
+- [ ] Linked issue (or "None" justified above)
+- [ ] ADR referenced (or "None" justified above)
+- [ ] `make kb-eval-outcomes` run locally; output pasted above
+- [ ] No new top-level vault folders without an ADR
+- [ ] Frontmatter validates on any new vault notes
+- [ ] Change is one coherent thing (not a grab-bag)
+
+<!--
+If this PR knowingly degrades an outcome eval, see CONTRIBUTING.md
+"The eval-gate contract" for the escape-hatch syntax. Add it as a
+top-level section in this PR body (NOT inside an HTML comment), with
+a one-line reason and a link to the ADR that authorizes the regression.
+
+Reasons without a linking ADR are rejected.
+-->