tech-lead-stack 1.0.1

package/.ai/hooks/README.md

@@ -0,0 +1,32 @@
+# Hooks (Ownership Gates)
+
+Hooks are declarative guards that enforce ownership and phase-transition safety at two critical points:
+1. **MCP Call-time**: When an AI agent attempts to call a tool (skill), the middleware evaluates the target skill against these guards. Unsafe actions are blocked *before* execution.
+2. **Commit/CI-time**: Enforced via `.husky/pre-commit` and CI jobs to ensure human-in-the-loop workflows aren't bypassed.
+
+## Schema
+
+Each JSON file in this directory represents a guard with the following structure:
+
+```json
+{
+  "id": "guard-name",
+  "description": "Human-readable description of what this guard does",
+  "appliesToPhase": ["deploy", "build"],
+  "condition": {
+    "requireKi": "review-report",
+    "requireKiStatus": "passed",
+    "actorTypeNot": "USER",
+    "consumesApprovedKi": true,
+    "diffContains": ["**/auth/**", "**/payments/**", "infra/**"]
+  },
+  "action": "block" | "warn" | "require-human-approve",
+  "message": "The message returned when the guard is triggered."
+}
+```
+
+## Ownership Axis
+Guards map strongly to the ownership axis:
+- They prevent AI actors (`actorType != USER`) from self-approving high-risk actions like deployments or scaling.
+- They enforce strict phase transitions (e.g. `build` cannot proceed if the upstream specification KI is not `human-approved`).
+- They enforce protective boundaries around critical paths (auth, payments).

package/.ai/hooks/build-requires-approved-spec.json

@@ -0,0 +1,10 @@
+{
+  "id": "build-requires-approved-spec",
+  "description": "Block build skills if upstream spec KI is unapproved",
+  "appliesToPhase": ["build"],
+  "condition": {
+    "consumesApprovedKi": true
+  },
+  "action": "block",
+  "message": "Cannot build: upstream spec is not human-approved."
+}

package/.ai/hooks/deploy-requires-review.json

@@ -0,0 +1,11 @@
+{
+  "id": "deploy-requires-review",
+  "description": "Block deploy unless a review-report KI exists and passed",
+  "appliesToPhase": ["deploy"],
+  "condition": {
+    "requireKi": "review-report",
+    "requireKiStatus": "passed"
+  },
+  "action": "block",
+  "message": "Deployment requires a passing review-report KI."
+}

package/.ai/hooks/no-ai-approve-deploy.json

@@ -0,0 +1,10 @@
+{
+  "id": "no-ai-approve-deploy",
+  "description": "AI may never self-approve a ship/scale action",
+  "appliesToPhase": ["deploy", "scale"],
+  "condition": {
+    "actorTypeNot": "USER"
+  },
+  "action": "block",
+  "message": "AI is not permitted to self-approve deployment or scale actions."
+}

package/.ai/hooks/protected-paths.json

@@ -0,0 +1,10 @@
+{
+  "id": "protected-paths",
+  "description": "Require human approve when touching auth/payments/infra",
+  "appliesToPhase": ["build"],
+  "condition": {
+    "diffContains": ["**/auth/**", "**/payments/**", "infra/**"]
+  },
+  "action": "require-human-approve",
+  "message": "Modifications to protected paths require human approval."
+}

package/.ai/hr-skills/hr-ad-distributor.md

@@ -0,0 +1,61 @@
+---
+name: hr-ad-distributor
+description:
+  Publish and manage job advertisements across external platforms and the
+  internal ATS. Focuses on cross-channel listing parity and verified live
+  postings.
+cost: ~500 tokens
+modes: [read-only, mcp]
+surface: public
+phase: deploy
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [review-report]
+emits: [release]
+policies:
+  - user-sovereignty
+---
+
+# HR Ad Distributor (The Channel Publisher)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every distribution begins with **ATS
+> Discovery**. The agent must map the approved JD to existing live listings
+> before posting to prevent duplicates. Follow **MinimumCD** by treating each
+> channel as an incremental, independently verifiable publish.
+
+## 🎯 Verification Gates (Listing Parity)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Action**: Fetch the approved JD version and enumerate live listings across
+  LinkedIn and Ashby.
+- **Goal**: Identify duplicate or drifted postings before publishing anything
+  new.
+
+### Gate 1: Cross-Channel Parity
+
+- **Positive (Signal):** Title, requirements, comp band, and location are
+  identical across every channel and match the approved JD.
+- **Negative (Noise):** Drifted copy between LinkedIn and Ashby, or a stale JD
+  version.
+- **Action**: If Negative, block posting until every channel reflects the same
+  approved version.
+
+### Gate 2: Channel Configuration
+
+- **Positive (Pass):** Correct Ashby pipeline attached; LinkedIn category,
+  location, and workplace type set; the apply flow is tested.
+- **Negative (FAIL):** Wrong pipeline, a broken apply link, or a miscategorized
+  listing.
+
+## 📋 Outcome Actions
+
+- **Deliver**: A "Distribution Manifest" listing each live posting with its URL
+  and status (Ashby set to `Open`).
+- **Ethos**: One source, every channel. The approved JD is the single truth that
+  every listing must mirror.

package/.ai/hr-skills/hr-candidate-sourcer.md

@@ -0,0 +1,69 @@
+---
+name: hr-candidate-sourcer
+description:
+  Source passive candidates and enrich the pipeline with match-scored prospects.
+  Bridges the gap between the JD requirement set and the live talent market.
+cost: ~800 tokens
+modes: [read-only, mcp]
+surface: public
+phase: build
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [plan]
+emits: [diff]
+suggests: [code-review-checklist, pr-automator]
+policies:
+  - user-sovereignty
+---
+
+# HR Candidate Sourcer (The Precision Scout)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every sourcing run begins with **ATS
+> Discovery**. The HR agent must understand the requisition's must-haves and the
+> existing candidate pool before searching. Follow **MinimumCD** by identifying
+> the smallest set of high-signal profiles that move the search forward.
+
+## 🎯 Verification Gates (Match & Compliance)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Skill Usage Enforcement (NON-NEGOTIABLE):**
+  - **FORBIDDEN:** Direct sourcing without requisition context is prohibited.
+  - **IDE / MCP-enabled Agent:** You MUST call the MCP `get_skills` tool (which may be prefixed as `mcp_tech-lead-stack_get_skills` or `tech-lead-stack_get_skills` depending on client prefixing).
+  - **Chat UI (/chat):** You MUST call the internal `get_skill` tool.
+
+- **Action:** Identify the JD must-haves and enumerate candidates already in the
+  Ashby pipeline for this requisition.
+- **Target Records:** Inspect the finalized JD, the Ashby candidate list, and
+  prior outreach history.
+- **MANDATORY Guardrail:** Focus ONLY on profiles that map to a stated must-have.
+  Avoid "Goal Drift" by ignoring keyword-only matches or already-contacted
+  candidates.
+
+### Gate 1: Match Signal
+
+- **Positive (Signal):** The profile evidences the must-have skills, seniority,
+  and location constraints from the JD.
+- **Negative (Noise):** Keyword-only matches, wrong seniority, or ineligible
+  location.
+- **Action:** If Negative, expand to adjacent titles and skill synonyms rather
+  than lowering the bar.
+
+### Gate 2: Outreach Compliance & Dedupe
+
+- **Positive (Verified):** The candidate is not in-pipeline, not inside the
+  outreach cooldown window, and sourcing respects platform and privacy norms.
+- **Negative (Risk):** Re-contacting a live candidate or scraping restricted
+  data.
+
+## 📋 Outcome Actions
+
+- **Deliver**: A compliance-checked "Sourcing Longlist" with a match score and
+  status per prospect.
+- **Ethos**: Signal over volume. A short list of well-matched, uncontacted
+  prospects beats a wide net of noise.

package/.ai/hr-skills/hr-endorsement-synthesizer.md

@@ -0,0 +1,82 @@
+---
+name: hr-endorsement-synthesizer
+description:
+  Synthesize resumes and raw interviewer notes into an evidence-traceable client
+  shortlist of the top 3-5 applicants. Focuses on source fidelity, ranking
+  integrity, and a Gemini-driven synthesis pass.
+cost: ~950 tokens
+modes: [read-only, mcp]
+surface: public
+phase: build
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [plan]
+emits: [diff]
+suggests: [code-review-checklist, pr-automator, hr-interview-auditor]
+policies:
+  - user-sovereignty
+---
+
+# HR Endorsement Synthesizer (The Synthesis Engine)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every endorsement begins with **ATS
+> Discovery**. The agent must gather the interview notes, resumes, and scorecards
+> before synthesizing. Follow **MinimumCD** by grounding every endorsement claim
+> in the smallest verifiable unit of evidence.
+
+## 🎯 Verification Gates (Evidence & Ranking Integrity)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Skill Usage Enforcement (NON-NEGOTIABLE):**
+  - **FORBIDDEN:** Drafting an endorsement without interview evidence is prohibited.
+  - **IDE / MCP-enabled Agent:** You MUST call the MCP `get_skills` tool (which may be prefixed as `mcp_tech-lead-stack_get_skills` or `tech-lead-stack_get_skills` depending on client prefixing).
+  - **Chat UI (/chat):** You MUST call the internal `get_skill` tool.
+
+- **Action:** Identify the interviewed candidates, their resumes, and their raw
+  interview notes.
+- **Target Records:** Inspect the `hr-interview-auditor` scorecards, resumes, the
+  JD scorecard, and the agreed endorsement volume from the onboarding brief.
+- **MANDATORY Guardrail:** Focus ONLY on interviewed candidates for this
+  requisition. Avoid "Goal Drift" by ignoring any signal not tied to the JD
+  scorecard.
+
+### Gate 1: Evidence Fidelity
+
+- **Positive (Signal):** Every endorsement claim maps to a resume line or an
+  interviewer note.
+- **Negative (Noise):** AI-introduced qualifications, inferred seniority, or
+  invented metrics.
+- **Action:** If Negative, strike the unsourced claim and re-run synthesis with
+  the source map enforced.
+
+### Gate 2: Ranking Integrity
+
+- **Positive (Verified):** The ranking reflects weighted scorecard performance;
+  ties break on job-relevant evidence.
+- **Negative (Risk):** Ranking driven by resume prestige, recency bias, or a
+  padded slate beyond the agreed 3-5.
+
+## 🛠 Analysis Layer (The Hands)
+
+### 1. Source Bundle
+
+- Assemble the resume, raw interviewer notes, and scorecard for each candidate.
+
+### 2. Constrained Synthesis (Gemini)
+
+- Prompt Gemini to summarise **only** from the bundle, tagging each output
+  sentence to its source; strike untagged claims. The recruiter approves the
+  final ranking before the report ships.
+
+## 📋 Outcome Actions
+
+- **Deliver**: An "Endorsement Report" naming the top 3-5 applicants, each claim
+  tagged to its source.
+- **Ethos**: The model drafts, the recruiter decides. Gemini synthesises; it
+  never adjudicates fact.

package/.ai/hr-skills/hr-intake-specifier.md

@@ -0,0 +1,71 @@
+---
+name: hr-intake-specifier
+description:
+  Draft high-fidelity requisition intake briefs from new-client kickoff calls.
+  Focuses on requirement completeness, role viability, and account context.
+cost: ~600 tokens
+modes: [read-only, mcp]
+surface: public
+phase: specify
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [intent-brief]
+emits: [spec]
+suggests: [planning-expert, vertical-slice-decomposer]
+policies:
+  - user-sovereignty
+---
+
+# HR Intake Specifier (The Requirements Architect)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every intake begins with **ATS
+> Discovery**. The agent must audit the client account and existing requisitions
+> before capturing a single new requirement. Follow **MinimumCD** by defining the
+> "Minimum Viable Requisition" needed to open the search.
+
+## 🎯 Verification Gates (Requirement Integrity)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Action**: Research the state of the client account record, open requisitions,
+  and prior placement history in Ashby.
+- **Goal**: Understand the "Pattern Language" of the client (e.g., seniority
+  norms, comp bands, must-have vs nice-to-have culture).
+
+### Gate 1: Requirement Completeness
+
+- **Positive (Signal):** Role, seniority, must-haves, nice-to-haves, comp band,
+  and location/remote policy are all explicitly captured.
+- **Negative (Noise):** Vague titles, missing comp band, or a duplicate of an
+  existing open requisition.
+- **Action**: If Negative, force a "Requirement Deduplication" pass against the
+  ATS before opening the search.
+
+### Gate 2: Role Viability Gate
+
+- **Positive (Pass):** The comp band and must-have list are consistent with the
+  current market for the role and location.
+- **Negative (FAIL):** Unfillable combination (e.g., senior scope at junior band,
+  or more than 8 hard must-haves).
+
+## 🛠 Analysis Layer (The Hands)
+
+### 1. Account Heartbeat
+
+- Verify existing requisitions and identify any duplicate or re-opened search.
+
+### 2. Requirement Draft
+
+- Define the `Must-Have` and `Nice-to-Have` sets for the proposed requisition.
+
+## 📋 Outcome Actions
+
+- **Deliver**: An "Account Onboarding Brief" for sourcing and advertising
+  ingestion.
+- **Ethos**: Precision over Assumption. A brief should be so clear that sourcing
+  requires zero "back-and-forth" with the client.

package/.ai/hr-skills/hr-interview-auditor.md

@@ -0,0 +1,60 @@
+---
+name: hr-interview-auditor
+description:
+  Evaluate applicants against the requisition scorecard with evidence-backed
+  ratings. Focuses on rubric coverage, evidence capture, and bias control.
+cost: ~500 tokens
+modes: [read-only, mcp]
+surface: public
+phase: review
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [diff]
+emits: [review-report]
+suggests: [pr-automator, qa-handover-generator, hr-endorsement-synthesizer]
+policies:
+  - user-sovereignty
+---
+
+# HR Interview Auditor (The Signal Auditor)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every interview begins with **ATS
+> Discovery**. The agent must review the resume and the JD scorecard before the
+> conversation. Follow **MinimumCD** by grounding each competency rating in the
+> smallest verifiable piece of behavioural evidence.
+
+## 🎯 Verification Gates (Rubric Integrity)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Action**: Research the applicant's resume, the JD scorecard, and the current
+  Ashby stage.
+- **Goal**: Map every must-have competency to at least one planned question.
+
+### Gate 1: Rubric Coverage
+
+- **Positive (Signal):** Every must-have competency on the scorecard was probed
+  with at least one question.
+- **Negative (Noise):** Whole competency areas left unassessed, or time spent on
+  off-rubric tangents.
+- **Action**: If Negative, re-cover the missed competency before closing the
+  interview.
+
+### Gate 2: Evidence & Bias Gate
+
+- **Positive (Verified):** Each rating is backed by a specific example or quote,
+  and references job-relevant evidence only.
+- **Negative (Risk):** "Seemed strong" with no example, or affinity/halo signals
+  standing in for evidence.
+
+## 📋 Outcome Actions
+
+- **Deliver**: Structured "Interview Notes" and a scored rubric, ready for
+  `hr-endorsement-synthesizer` ingestion.
+- **Ethos**: No score without evidence. A rating a client cannot trace to a
+  concrete signal is void.

package/.ai/hr-skills/hr-jd-drafter.md

@@ -0,0 +1,61 @@
+---
+name: hr-jd-drafter
+description:
+  Transform intake notes or a client-provided draft into a finalized,
+  market-ready Job Description. Focuses on requirement fidelity and inclusive,
+  compliant language.
+cost: ~500 tokens
+modes: [read-only, mcp]
+surface: public
+phase: specify
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [intent-brief]
+emits: [spec]
+suggests: [planning-expert, vertical-slice-decomposer]
+policies:
+  - user-sovereignty
+---
+
+# HR JD Drafter (The Role Narrator)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every draft begins with **ATS
+> Discovery**. The agent must audit the intake brief and any client-provided JD
+> before writing. Follow **MinimumCD** by capturing the "Minimum Viable
+> Requirement" set that still attracts the right candidate.
+
+## 🎯 Verification Gates (JD Fidelity)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Action**: Fetch the account onboarding brief, any client-supplied JD, and
+  prior JDs for adjacent roles at this client.
+- **Goal**: Determine whether to synthesize from call notes or reformat a
+  client-provided draft.
+
+### Gate 1: Requirement Fidelity
+
+- **Positive (Signal):** Every must-have from the intake brief is represented;
+  responsibilities map to the agreed scope.
+- **Negative (Noise):** Invented requirements, un-agreed scope, or omitted
+  deal-breakers.
+- **Action**: If Negative, reconcile the draft against the intake brief before
+  finalizing.
+
+### Gate 2: Inclusive & Compliant Language
+
+- **Positive (Pass):** Gender-neutral, bias-free phrasing; requirements split
+  into essential vs preferred; EEO-safe wording.
+- **Negative (FAIL):** Coded terms, unnecessary degree gates, or inflated "X+
+  years" requirements.
+
+## 📋 Outcome Actions
+
+- **Deliver**: A finalized, market-ready JD ready for multi-channel distribution.
+- **Ethos**: Clarity attracts fit. A precise, inclusive JD widens the funnel
+  without diluting the bar.

package/.ai/hr-skills/hr-pipeline-translator.md

@@ -0,0 +1,58 @@
+---
+name: hr-pipeline-translator
+description:
+  Translate recruitment pipeline activity into clear client status updates.
+  Bridges the gap between ATS movement and stakeholder-facing value.
+cost: ~600 tokens
+modes: [read-only, mcp]
+surface: public
+phase: deploy
+kind: skill
+domain: hiring
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [review-report]
+emits: [release]
+policies:
+  - user-sovereignty
+---
+
+# HR Pipeline Translator (The Status Bridge)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every update begins with **ATS
+> Discovery**. The agent must understand the "Contextual Impact" of each stage
+> transition before framing it. Follow **MinimumCD** by celebrating the
+> completion of small, verifiable pipeline milestones.
+
+## 🎯 Verification Gates (Clarity & Impact)
+
+### Phase 0: ATS Discovery (MANDATORY)
+
+- **Action**: Identify the stage transitions in Ashby since the last update.
+- **Goal**: Differentiate "Pipeline Noise" (auto-rejections, duplicates) from
+  "Real Movement" (screens, interviews, endorsements, offers).
+
+### Gate 1: The "So What?" Filter
+
+- **Positive (Signal):** Successfully linked a stage change (e.g., "3 candidates
+  advanced to onsite") to a client-relevant outcome.
+- **Negative (Noise):** Listing raw applicant counts or system events as
+  "Status."
+- **Action**: If Negative, pivot to "Search Health" framing.
+
+### Gate 2: Stakeholder Empathy
+
+- **Positive (Pass):** The report uses concise, decision-maker language and names
+  items awaiting client action.
+- **Negative (FAIL):** Burying the client's pending decisions or overstating thin
+  progress.
+
+## 📋 Outcome Actions
+
+- **Deliver**: A "Client Pipeline Update" formatted for email or Slack briefings
+  (routine dispatch, tri-weekly sync, or async PM-tool update).
+- **Ethos**: Movement is Meaning. Translate "5 profiles reviewed" into "we have
+  narrowed to a stronger, tighter slate."

package/.ai/pm-skills/pm-action-item-mapper.md

@@ -0,0 +1,61 @@
+---
+name: pm-action-item-mapper
+description:
+  Translate meeting notes into actionable technical tasks linked to code.
+  Ensures full traceability from product intent to technical footprint.
+cost: ~500 tokens
+modes: [read-only, mcp]
+surface: public
+phase: build
+kind: skill
+domain: product
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+consumes: [plan]
+emits: [diff]
+suggests: [code-review-checklist, pr-automator]
+policies:
+  - user-sovereignty
+  - diagnosis-first
+---
+
+# PM Action Item Mapper (The Traceability Link)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every mapping beginning with
+> **Tech-Stack Discovery**. The agent must identify the specific logic nodes
+> (files/functions) that correspond to the meeting decisions. Follow
+> **MinimumCD** by linking intent to small, verifiable code changes.
+
+## 🎯 Verification Gates (Discovery & Mapping)
+
+### Phase 0: Tech-Stack Discovery (MANDATORY)
+
+- **Action**: Locate the core modules discussed in the notes using `list_dir` or
+  `grep_search`.
+- **Target**: Find data models, API routes, or UI components that match the
+  "Decision Context."
+
+### Gate 1: Intent-to-Node Traceability
+
+- **Positive (Signal):** Every decision in the meeting notes is mapped to one or
+  more specific files/functions.
+- **Negative (Noise):** Decision "float" where an action item has no clear
+  technical home.
+- **Action:** If Negative, report as a "Scope Fragility" and propose the
+  creation of a new module or extension of an existing one.
+
+### Gate 2: Logic Integrity
+
+- **Positive (Pass):** The proposed changes conform to existing patterns (e.g.,
+  if the user says "add logging", use the existing `Telemetry` service).
+- **Negative (FAIL):** The proposed change would introduce "Pattern Drift."
+
+## 📋 Outcome Actions
+
+- **Deliver**: A mapping table of: `Decision Item` -> `Target Logic Node` ->
+  `Technical Action`.
+- **Ethos**: Traceability over Speed. Never leave an action item unmapped to a
+  potential codebase impact.

package/.ai/pm-skills/pm-backlog-auditor.md

@@ -0,0 +1,57 @@
+---
+name: pm-backlog-auditor
+description:
+  Validate project backlog for logical consistency and feasibility. Detects
+  circular dependencies and missing technical prerequisites.
+cost: ~450 tokens
+modes: [read-only, mcp]
+surface: public
+phase: maintain
+kind: skill
+domain: product
+ownership:
+  drive: human-ai
+  approve: human
+targets: [local, api, subscription]
+minModelClass: small
+policies:
+  - user-sovereignty
+  - diagnosis-first
+---
+
+# PM Backlog Auditor (The Logic Gate)
+
+> [!IMPORTANT] **G-Stack Methodology**: Every backlog audit begins with
+> **Tech-Stack Discovery**. The agent must map backlog items to the current
+> codebase state to verify feasibility. Follow **MinimumCD** by ensuring tasks
+> are ordered in small, sequential logic blocks.
+
+## 🎯 Verification Gates (Feasibility & Flow)
+
+### Phase 0: Tech-Stack Discovery (MANDATORY)
+
+- **Action**: Audit the root `task.md` or provided backlog against the project
+  structure.
+- **Goal**: Check if the "System Primitives" (DB, Auth, core APIs) exist for the
+  listed tasks.
+
+### Gate 1: Pre-requisite Logic
+
+- **Positive (Signal):** Tasks are ordered logically (e.g., Schema -> API ->
+  UI).
+- **Negative (Noise):** UI tasks listed before their data-source is defined.
+- **Action**: Flag order violations as "Blocking Dependency" risks.
+
+### Gate 2: Scope Creep Detection
+
+- **Positive (Pass):** Every task has a clear boundary and maps to a single
+  "Value Unit."
+- **Negative (FAIL):** Tasks that attempt to solve multiple unrelated problems
+  simultaneously.
+
+## 📋 Outcome Actions
+
+- **Deliver**: A "Backlog Integrity Report" with a revised, logically-optimal
+  task order.
+- **Ethos**: Logical Rigor. A backlog that ignores technical prerequisites is a
+  roadmap to failure.