docs: factory integration grill — decision record, ADRs, and chunk scope update

- Decision record covering 12 decisions from the factory integration grill
- ADR-0008 (factory boundary: this repo is a provider, not a factory instance)
- ADR-0009 (flat skill taxonomy with category metadata in frontmatter)
- ADR-0010 (role skills in .agents/skills/; core/agents/ for subagent definitions)
- Issue 0013 (LESSONS.md at repo root)
- Issue 0014 (docs/spec/ living spec layer + VISION.md refactor)
- ROADMAP Chunk 3 scope expanded: skills rebuild, new skills (session-handoff,
  governance-check, git-guardrails, write-adr), IaC/Gitea global optional
- Per-skill process: implementation guidance Sections 4-5 and skills index
  referenced as starting point before web research and grilling
- factory-research-gaps-conflicts.md marked superseded

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/adr/0008-factory-boundary.md

@@ -0,0 +1,7 @@
+# This repo is a provider of factory tooling, not a factory instance
+
+This repo ships skills, governance, and conventions to project repos — it does not itself adopt the full factory structure (LESSONS.md, docs/spec/, eval infrastructure, references/) as if it were a software project using the factory. Conflating the two layers would mix config-delivery concerns with application concerns, make the repo harder to upgrade (changes to the factory shape would break all consumers simultaneously), and obscure what is a global primitive vs. what is project-specific.
+
+Exception: artefacts also needed while building *this repo itself* are added here in addition to being scaffolded for project repos. LESSONS.md and docs/spec/ qualify — this repo undergoes active development and benefits from the same feedback and spec hygiene it ships to others. This exception is bounded: it applies only when the artefact genuinely serves the repo's own development, not to import the full factory shape by default.
+
+Orchestration agents (cross-project automation) are a natural future extension at Chunk 5, not a reason to change the provider boundary now.

docs/adr/0009-flat-skill-taxonomy.md

@@ -0,0 +1,7 @@
+# Flat skill directories with category metadata, not nested paths
+
+Skills are stored as flat directories directly under `.agents/skills/` (`grill-me/SKILL.md`, not `design/grill-me/SKILL.md`). Category organisation is expressed via `metadata: category:` in each SKILL.md frontmatter rather than directory nesting.
+
+Nested paths were evaluated and rejected for three reasons. First, Claude Code discovers skills exactly one level deep under `~/.claude/skills/` — a skill at `~/.claude/skills/design/grill-me/SKILL.md` is invisible to the tool. Second, the agentskills.io open standard specifies that the `name` field must match the parent directory name, implying a flat structure at the skills root; no nested discovery is defined in the spec. Third, `install.sh` iterates `for skill_dir in .agents/skills/*/` — one level only; nested paths would require a traversal rewrite before a single nested skill could be deployed.
+
+Category metadata achieves the same organisational goals: the Management App can group skills by category, a generated README can cluster them, and the category is machine-readable for tooling — all without path changes, pipeline changes, or deviation from the open standard. If Claude Code adds nested discovery in a future release, paths can be restructured then with evidence rather than speculatively now.

docs/adr/0010-role-skills-vs-subagents.md

@@ -0,0 +1,7 @@
+# Role skills in .agents/skills/, core/agents/ reserved for subagent definitions
+
+Role skills (Architect, Developer, Reviewer, Security, QA, Ops) live in `.agents/skills/` with `category: roles`. They are ordinary skills that activate a cognitive mode in the current conversation — loaded on trigger, follow the standard SKILL.md authoring format, and use the same deployment pipeline as every other skill. Placing them in a separate `core/agents/` directory would require a distinct deployment path, a distinct provider adapter, and a distinct discovery mechanism for no functional gain.
+
+`core/agents/` is reserved for a distinct content type: provider-agnostic subagent definitions that run in isolated execution contexts (`context: fork` in Claude Code terms). These are skills or agents that need a fresh context window, a dedicated system prompt, and no access to the parent conversation history. The Claude Code adapter translates `core/agents/` definitions to `.claude/agents/`. This is structurally different from a role skill that loads inline — the isolation boundary is the defining characteristic, not the cognitive mode.
+
+The factory research conflates these two into a single `roles/` skill category. The distinction matters here because Claude Code's subagent execution model is meaningfully different from skill activation, and the provider adapter pattern requires them to be in separate source locations to translate correctly.