docs: add review infrastructure and convention pack documentation

.uf/dewey/learnings/constitution-principle-v-20260821T201858-jay-flowers.md

@@ -0,0 +1,10 @@
+---
+tag: constitution-principle-v
+author: jay-flowers
+category: gotcha
+created_at: 2026-08-21T20:18:58Z
+identity: constitution-principle-v-20260821T201858-jay-flowers
+tier: draft
+---
+
+When documenting Constitution Principle V (Security by Default) on the Unbound Force website, the content MUST be sourced from the upstream .specify/memory/constitution.md, not from GitHub issue descriptions or spec summaries. Principle V covers four MUST rules: (1) dependencies verified by content hash SHA256, (2) all external inputs validated and sanitized, (3) components operate with minimum permissions, and (4) external dependencies must be justified. Compound severity escalation does NOT belong under Principle V — it is defined in the severity.md convention pack, which is a Layer 2 governance artifact, not a Layer 1 constitutional principle. This distinction matters because placing convention pack mechanics inside a constitutional principle misrepresents the governance hierarchy. The spec review council caught this as a CRITICAL finding and it required correction before implementation could proceed.

.uf/dewey/learnings/divisor-personas-20260821T201852-jay-flowers.md

@@ -0,0 +1,10 @@
+---
+tag: divisor-personas
+author: jay-flowers
+category: reference
+created_at: 2026-08-21T20:18:52Z
+identity: divisor-personas-20260821T201852-jay-flowers
+tier: draft
+---
+
+When documenting Divisor persona counts on the Unbound Force website, the correct number is 9 total: 6 review personas (Guard, Architect, Adversary, Testing, SRE, Curator) and 3 content personas (Scribe, Herald, Envoy). All 9 are discovered dynamically by scanning for divisor-*.md files and all 9 are invoked by the review council. The content personas participate in reviews but defer code-level findings to the review personas. The discovery mechanism (from uf.review-council.md) states "the invocation list comes solely from discovery, not from this table." Pre-existing site references vary between 5, 6, and 9 — always verify against the upstream scaffold at unbound-force/unbound-force/internal/scaffold/assets/opencode/agents/ which has the authoritative set of 9 divisor-*.md files.

.uf/dewey/learnings/review-infra-docs-20260821T201911-jay-flowers.md

@@ -0,0 +1,10 @@
+---
+tag: review-infra-docs
+author: jay-flowers
+category: pattern
+created_at: 2026-08-21T20:19:11Z
+identity: review-infra-docs-20260821T201911-jay-flowers
+tier: draft
+---
+
+During the review-infra-docs implementation, the spec review council (10 Divisor agents in parallel) identified 10 deduplicated finding themes across the spec artifacts. The most impactful finding was that compound severity escalation was misattributed to Constitution Principle V — 7 of 10 agents flagged this independently, demonstrating the value of multi-perspective review. The auto-fix pass addressed all findings in a single iteration, and the re-review confirmed all resolved. Key lesson: when documenting features that span multiple governance layers (constitution vs convention packs vs agent personas), always verify which layer the feature actually belongs to by reading the upstream source file, not relying on issue descriptions or memory.

.uf/dewey/learnings/website-docs-maintenance-20260821T201902-jay-flowers.md

@@ -0,0 +1,10 @@
+---
+tag: website-docs-maintenance
+author: jay-flowers
+category: pattern
+created_at: 2026-08-21T20:19:02Z
+identity: website-docs-maintenance-20260821T201902-jay-flowers
+tier: draft
+---
+
+When adding new pages to the website reference section (content/docs/reference/), the reference section index page at content/docs/reference/_index.md manually lists all reference pages with descriptions. New pages will appear in Hugo's sidebar automatically but will NOT appear on the _index.md landing page without a manual update. Always include a task to update _index.md when adding reference pages. Similarly, when modifying the constitution (e.g., adding a new principle), check all pages that reference the principle count — common locations include getting-started/_index.md, architecture.md, blog posts like the-8-phase-pipeline.md, and role-based guides (tester.md, product-owner.md). The count appears in more places than expected.

content/docs/getting-started/_index.md

@@ -50,7 +50,7 @@ Ready to dive in? Start with the [Quick Start](/docs/getting-started/quick-start
 - **[Common Workflows](/docs/getting-started/common-workflows/)** -- The `/unleash` autonomous pipeline, `/finale` shipping workflow, manual feature flows, bug fixes, and code reviews
 - **[Hero Artifacts](/docs/getting-started/artifacts/)** -- Inter-hero communication: envelope format, artifact types, and lifecycle data flow
 - **[Knowledge Retrieval with Dewey](/docs/getting-started/knowledge/)** -- Install and configure Dewey for semantic search across your repositories
-- **[Constitution](/docs/getting-started/constitution/)** -- The 4 core principles that govern all heroes and the governance model
+- **[Constitution](/docs/getting-started/constitution/)** -- The 5 core principles that govern all heroes and the governance model
 
 ## Design Philosophy
 

content/docs/getting-started/common-workflows.md

@@ -35,7 +35,7 @@ toc: true
 
 ### Branch Safety
 
-`/unleash` works with both Speckit (`NNN-*`) and OpenSpec (`opsx/*`) feature branches. It never runs on `main`. For Speckit branches, it validates that `spec.md` exists. For OpenSpec branches, it detects the change name from the branch (`opsx/<name>`) and reads tasks from `openspec/changes/<name>/tasks.md`.
+`/unleash` works with both Speckit (`speckit/NNN-*`) and OpenSpec (`opsx/*`) feature branches. It never runs on `main`. For Speckit branches, it validates that `spec.md` exists. For OpenSpec branches, it detects the change name from the branch (`opsx/<name>`) and reads tasks from `openspec/changes/<name>/tasks.md`.
 
 After `/unleash` completes, the demo step suggests running `/finale` to commit, push, and create a PR.
 
@@ -66,7 +66,7 @@ See also: [From Spec to Demo in One Command](/blog/unleash-in-practice/) — a n
 - Never commits without user approval of the commit message
 - If any step fails, stops immediately with context and options
 
-`/finale` works with both Speckit (`NNN-*`) and OpenSpec (`opsx/*`) branches. It is the natural complement to `/unleash` — `/unleash` builds, `/finale` wraps up the branch and creates a PR for review.
+`/finale` works with both Speckit (`speckit/NNN-*`) and OpenSpec (`opsx/*`) branches. It is the natural complement to `/unleash` — `/unleash` builds, `/finale` wraps up the branch and creates a PR for review.
 
 ## New Feature (End-to-End) {#new-feature-end-to-end}
 
@@ -147,6 +147,7 @@ The [Developer (Cobalt-Crush)](/docs/getting-started/developer/) creates the tec
   - **Adversary**: Security, resilience, error handling
   - **Testing**: Test architecture, coverage strategy, assertion depth
   - **SRE**: Release pipeline, dependency health, observability
+  - **Curator**: Documentation gaps, blog/tutorial opportunities, website issue filing
 
 If the council returns REQUEST CHANGES, the developer addresses findings and re-submits (up to 3 iterations before escalation to human review).
 
@@ -315,7 +316,7 @@ This creates `openspec/changes/fix-auth-timeout/` with:
 - `design.md` -- Technical approach
 - `tasks.md` -- Implementation steps
 
-This creates an `opsx/fix-auth-timeout` branch and checks it out automatically. The `opsx/` prefix distinguishes OpenSpec branches from Speckit branches (`NNN-<short-name>`) in `git branch` output.
+This creates an `opsx/fix-auth-timeout` branch and checks it out automatically. The `opsx/` prefix distinguishes OpenSpec branches from Speckit branches (`speckit/NNN-<short-name>`) in `git branch` output.
 
 ### 2. Implement
 
@@ -370,7 +371,7 @@ The council discovers available Divisor persona agents in `.opencode/agents/divi
 | **SRE**       | Release pipeline, dependency health, configuration, runtime observability                |
 | **Curator**   | Documentation gaps, blog/tutorial opportunities, website issue filing                    |
 
-> **Note**: The table above lists the 6 review personas that participate in code review. Three additional content personas — Scribe (technical documentation), Herald (blog/announcements), and Envoy (public communications) — are invoked separately for content creation tasks and do not participate in the code review council.
+> **Note**: The table above lists the 6 review personas with dedicated code review focus areas. Three additional content personas — Scribe (technical documentation), Herald (blog/announcements), and Envoy (public communications) — are also discovered and invoked by the review council, where they evaluate documentation quality, content opportunities, and communication clarity. Their code-level findings are deferred to the review personas above.
 
 ### CI Gate (Phase 1a and 1b)
 

content/docs/getting-started/constitution.md

@@ -1,6 +1,6 @@
 ---
 title: "Constitution"
-description: "The 4 core principles that govern all Unbound Force heroes — Autonomous Collaboration, Composability First, Observable Quality, and Testability."
+description: "The 5 principles governing all Unbound Force heroes — Autonomous Collaboration, Composability, Observable Quality, Testability, Security by Default."
 lead: "The foundational principles that govern every hero in the Unbound Force swarm."
 date: 2026-03-29T00:00:00+00:00
 draft: false
@@ -10,7 +10,7 @@ toc: true
 
 ## What the Constitution Is
 
-The Unbound Force constitution is the highest-authority document in the organization. It defines four core principles that every hero must follow and every hero constitution must align with. All development practices, pull request reviews, specification pipelines, and quality gates operate within the boundaries set by these principles.
+The Unbound Force constitution is the highest-authority document in the organization. It defines five core principles that every hero must follow and every hero constitution must align with. All development practices, pull request reviews, specification pipelines, and quality gates operate within the boundaries set by these principles.
 
 The constitution exists because an AI agent swarm that generates code rapidly needs structural constraints to prevent collapse. Without shared principles, heroes would make incompatible assumptions about communication, quality, and testability. The constitution makes those assumptions explicit, enforceable, and versioned.
 
@@ -82,6 +82,19 @@ Every component built within the Unbound Force ecosystem MUST be testable in iso
 
 **Rationale**: AI agents generate code rapidly. If that code is not structurally testable, the resulting system will quickly collapse under its own unverified complexity. The Testability principle ensures that velocity never comes at the cost of verifiability.
 
+## Principle V: Security by Default
+
+Every component built within the Unbound Force ecosystem MUST treat security as a structural property, not a review-time afterthought. Supply chain integrity, input validation, and least privilege MUST be enforced by design.
+
+### MUST Rules
+
+- Dependencies MUST be verified by content hash (SHA256 or equivalent) when downloaded outside a package manager's built-in verification. CI pipelines MUST pin actions and reusable workflows by commit SHA, not mutable tags.
+- All external inputs (user input, API payloads, file contents, environment variables used as data) MUST be validated and sanitized before reaching any security-sensitive operation.
+- Components MUST operate with the minimum permissions necessary. Secrets MUST be scoped to the narrowest context needed. File permissions MUST default to restrictive values (0o644 for files, 0o755 for executables and directories).
+- Before adding an external dependency, the adopter MUST justify that the project's existing toolchain cannot cover the same use case. Every dependency is attack surface; the default answer is "do not add."
+
+**Rationale**: AI agents make adding dependencies and generating code trivially fast. Without structural security guardrails, the attack surface of the system grows with each generation cycle.
+
 ## Hero Constitution Alignment
 
 Each hero repository maintains its own constitution that extends the organizational constitution:
@@ -109,7 +122,7 @@ The constitution follows semantic versioning:
 | Change Type                                                   | Version Bump | Example                               |
 | ------------------------------------------------------------- | ------------ | ------------------------------------- |
 | Principle removal or incompatible redefinition of a MUST rule | MAJOR        | Removing Testability principle        |
-| New principle added or materially expanded guidance           | MINOR        | Adding Testability (v1.0.0 -> v1.1.0) |
+| New principle added or materially expanded guidance           | MINOR        | Adding Security by Default            |
 | Clarifications, wording, or non-semantic refinements          | PATCH        | Rewording a rationale paragraph       |
 
 ### Compliance Review
@@ -132,7 +145,7 @@ Violations are CRITICAL severity and non-negotiable -- they must be resolved bef
 
 The `/constitution-check` command automates this assessment. OpenSpec proposals also include a Constitution Alignment section where each principle is evaluated against the proposed change.
 
-The constitution is versioned (currently v1.1.0) and the check validates against the version referenced in the project's `parent_constitution` field. See the [contributing guide](/docs/contributing/) for how this fits into the specification pipeline.
+The constitution is versioned (currently v1.0.0) and the check validates against the version referenced in the project's `parent_constitution` field. See the [contributing guide](/docs/contributing/) for how this fits into the specification pipeline.
 
 ## Governance Hierarchy
 
@@ -150,5 +163,5 @@ A convention pack cannot override a constitutional principle. A command cannot b
 
 - Read [Hero Artifacts](/docs/getting-started/artifacts/) to understand the envelope format and artifact types referenced in Principle I
 - See [Common Workflows](/docs/getting-started/common-workflows/) for how the constitution gates the specification pipeline
-- Read about [convention packs](/docs/getting-started/developer/#convention-packs/) — the constitution sets the floor; convention packs raise the bar with specific, severity-classified coding standards
+- Read about [convention packs](/docs/reference/convention-packs/) — the constitution sets the floor; convention packs raise the bar with specific, severity-classified coding standards
 - Explore the [Team](/docs/team/) pages to see how each hero implements these principles