taketomarket 0.1.0

package/references/context-loading.md

@@ -0,0 +1,107 @@
+# Context Loading Strategy
+
+## Overview
+
+takeToMarket uses a two-tier context loading strategy to maximize the usable context window for actual work. Every reference file in `.marketing/` has a compact Tier 1 summary and a full Tier 2 body. Workflows load only what they need.
+
+## Tier 1: Universal Summaries
+
+**Budget:** ~2,000 tokens total across all 9 reference files.
+
+Tier 1 content is the `<!-- _SUMMARY -->` block at the top of each reference file, delimited by `<!-- END_SUMMARY -->`. It contains the minimum context needed to enforce positioning invariants, check brand voice, and understand campaign scope.
+
+**When loaded:** Every workflow loads all Tier 1 summaries. This is non-negotiable -- positioning enforcement requires ambient awareness of the positioning summary in every context.
+
+**Implementation:** The AI reads from the start of the file to the `<!-- END_SUMMARY -->` delimiter. Everything below the delimiter is Tier 2.
+
+## Tier 2: Full Reference Content
+
+Tier 2 is the complete file content below `<!-- END_SUMMARY -->`. It includes detailed tables, examples, history, and configuration.
+
+**When loaded:** Only by workflows that need the full content for their specific task. Loading Tier 2 for all files would consume ~15,000-20,000 tokens -- acceptable for production workflows but wasteful for state checks.
+
+## Per-File Token Budgets
+
+| File | Tier 1 Budget | Tier 2 Loaded By |
+|------|---------------|------------------|
+| POSITIONING.md | ~150 words | produce, verify, positioning-check |
+| BRAND.md | ~100 words | produce, verify, brand-refresh |
+| ICP.md | ~100 words | produce, verify, icp-refresh, brief |
+| CHANNELS.md | ~80 words | brief, measure |
+| STATE.md | frontmatter only | state, resume, next, health |
+| CALENDAR.md | ~80 words | brief, new-campaign |
+| COMPETITORS.md | ~80 words | research, competitor-scan |
+| METRICS.md | ~80 words | measure, brief |
+| LEARNINGS.md | ~80 words | brief, learn |
+
+**Total Tier 1:** ~830 words / ~1,100 tokens (well within the ~2,000 token budget)
+
+## Workflow-to-Reference Loading Matrix
+
+| Workflow | Tier 1 (all summaries) | Tier 2 Files Loaded |
+|----------|----------------------|---------------------|
+| /ttm-init | N/A (creates files) | N/A |
+| /ttm-new-campaign | Yes | CALENDAR.md |
+| /ttm-brief | Yes | ICP.md, CHANNELS.md, METRICS.md, CALENDAR.md |
+| /ttm-produce | Yes | POSITIONING.md, BRAND.md, ICP.md + playbook |
+| /ttm-verify | Yes | POSITIONING.md, BRAND.md, ICP.md + gates |
+| /ttm-review | Yes | None (human review) |
+| /ttm-fix | Yes | Same as verify |
+| /ttm-ship | Yes | CHANNELS.md |
+| /ttm-measure | Yes | METRICS.md, CHANNELS.md |
+| /ttm-learn | Yes | LEARNINGS.md, METRICS.md |
+| /ttm-state | Yes | None |
+| /ttm-resume | Yes | None |
+| /ttm-health | Yes | None |
+| /ttm-positioning-check | Yes | POSITIONING.md |
+| /ttm-positioning-shift | Yes | POSITIONING.md |
+| /ttm-brand-refresh | Yes | BRAND.md |
+| /ttm-icp-refresh | Yes | ICP.md |
+| /ttm-competitor-scan | Yes | COMPETITORS.md |
+| /ttm-research | Yes | COMPETITORS.md |
+
+## Rules for Workflow Authors
+
+1. **Always load Tier 1 summaries.** Every workflow starts by reading the `_SUMMARY` block from all 9 reference files. This ensures positioning enforcement is always active.
+
+2. **Only load Tier 2 when your workflow needs the full content.** Check the loading matrix above. If your workflow is not listed as a Tier 2 consumer for a file, do not load the full file.
+
+3. **STATE.md is special.** It uses YAML frontmatter instead of `_SUMMARY` blocks. Tier 1 is the frontmatter (parsed by `ttm-tools.cjs state read`). Tier 2 is the Markdown body.
+
+4. **Campaign-specific files are always full-loaded.** Files inside `CAMPAIGNS/<slug>/` do not use the two-tier pattern. They are loaded in full by the workflow that owns that campaign phase.
+
+5. **Playbooks are Tier 2 only.** Playbooks live in the plugin's `playbooks/` directory (not in `.marketing/`). They are loaded only by the produce workflow, one at a time, based on the campaign brief's channel selection.
+
+## Implementation Details
+
+### Delimiter Format
+
+```markdown
+<!-- _SUMMARY: Tier 1 context (loaded universally, <200 words) -->
+[compact summary content]
+<!-- END_SUMMARY -->
+
+[full Tier 2 content]
+```
+
+### Reading Tier 1 Only
+
+The AI reads from line 1 to the line containing `<!-- END_SUMMARY -->`. Everything after is ignored unless the workflow explicitly requests Tier 2.
+
+### .marketing/ Directory Structure
+
+```
+.marketing/
+├── POSITIONING.md
+├── BRAND.md
+├── ICP.md
+├── CHANNELS.md
+├── STATE.md
+├── CALENDAR.md
+├── COMPETITORS.md
+├── METRICS.md
+├── LEARNINGS.md
+└── CAMPAIGNS/
+```
+
+Note: The `.marketing/` directory does NOT contain a `PLAYBOOKS/` subdirectory. Playbooks live in the plugin's `playbooks/` directory and are loaded by reference during the Produce phase.

package/references/learnings-extraction.md

@@ -0,0 +1,94 @@
+# Learnings Extraction Guide
+
+Reference file for /ttm-archive workflow. Provides structured instructions for extracting
+compound learnings from a completed campaign before archival. Loaded via @-syntax to keep
+the archive workflow under 500 lines.
+
+## Extraction Structure
+
+### What Worked
+
+Scan the campaign artifacts for indicators of success:
+
+- **Gate passes on first attempt:** Check STATE.md gate fields -- any gate with `pass` result AND verify.run_count = 1 indicates a strong pattern worth extracting.
+- **High review scores:** Check REVIEW-FEEDBACK-*.md for "approved" or "ship-ready" without revision requests.
+- **No fix loops:** If fix.run_count is null or 0, the campaign passed verification without needing fixes -- extract the approach that drove this.
+- **Asset-level wins:** Check MANIFEST.json for assets with review_status = "approved" on first submission.
+
+For each success, identify the specific pattern or approach that drove it (positioning angle, hook strategy, format choice, channel timing).
+
+### What Didn't Work
+
+Scan for indicators of failure or friction:
+
+- **Gate failures:** Any gate field with `fail` result -- check VERIFICATION.md for the specific failure details and root cause.
+- **Fix loops:** If fix.run_count > 0, the campaign needed corrections. Check FIX-BRIEF-*.md for what was wrong and what was changed.
+- **Review rejections:** Check REVIEW-FEEDBACK-*.md for revision requests -- extract what the reviewer flagged and why.
+- **Multiple verification runs:** If verify.run_count > 1, initial assets failed quality gates -- determine what was missed.
+
+For each failure, categorize using the Root-Cause Taxonomy below and extract the lesson.
+
+### Campaign-Level Decisions
+
+Extract key strategic decisions made during the campaign for future reference:
+
+- **Positioning anchor chosen:** Which specific positioning element from POSITIONING.md was the primary anchor? Did it resonate or need adjustment?
+- **Channel mix rationale:** Why were the chosen channels selected? Was the rationale validated by results?
+- **Hook strategy:** What hook approach was used (pain-point, curiosity, authority, social proof)? How did it perform?
+- **ICP targeting:** Which ICP segment was targeted? Were there signals of fit or misfit?
+- **Format decisions:** Why was the chosen format selected? Would a different format have worked better?
+
+## Root-Cause Taxonomy
+
+Every lesson extracted from a failed or underperforming element must be categorized into one of these root causes:
+
+| Category | Description |
+|----------|-------------|
+| positioning-drift | Asset deviated from POSITIONING.md -- used competitor language, wrong value prop, or off-brand messaging |
+| weak-hook | Opening failed to capture attention -- generic intro, no specific pain addressed, buried lede |
+| wrong-channel | Content published on ineffective channel for target ICP or content type |
+| bad-timing | Published at wrong time, wrong cadence, or conflicted with external events |
+| unverifiable-claim | Claim lacked proof point, source, or measurable evidence |
+| broken-funnel | CTA or conversion path was broken, misaligned, or missing |
+| creative-fatigue | Repeated format or angle with diminishing returns -- audience saturation |
+
+For successful elements, use category `success` with a description of what pattern drove the win.
+
+## Output Format
+
+Each extracted lesson must produce a table row for LEARNINGS.md:
+
+```
+| Date | Campaign | Category | Lesson | Action Taken |
+```
+
+Field definitions:
+
+- **Date:** Archive date (today's ISO date, e.g., 2024-03-15)
+- **Campaign:** Campaign slug (e.g., `spring-launch-2024`)
+- **Category:** One of the root-cause taxonomy values above, or `success` for wins
+- **Lesson:** One-sentence summary of what happened and why (be specific, not generic)
+- **Action Taken:** Recommended or completed reference file update, or `none` if no systemic fix needed
+
+Example rows:
+```
+| 2024-03-15 | spring-launch | success | Pain-point hook with specific dollar amount drove 3x click-through vs generic hooks | Updated BRAND.md hook guidelines |
+| 2024-03-15 | spring-launch | weak-hook | Email subject line was generic "Check out our new feature" with 8% open rate | none -- one-off issue |
+| 2024-03-15 | spring-launch | positioning-drift | Blog post used "best-in-class" (competitor language) instead of our differentiation | Added to POSITIONING.md anti-patterns |
+```
+
+## Artifact Scanning Guide
+
+Read these files from the campaign directory to extract learnings:
+
+| File | What to Extract |
+|------|----------------|
+| `STATE.md` (frontmatter) | Gate results (gate.* fields), fix counts (fix.run_count), phase timestamps, verify run count |
+| `MANIFEST.json` | Per-asset results, review status, asset types produced |
+| `BRIEF.md` | Original strategy, positioning anchor, target ICP, channel mix rationale |
+| `VERIFICATION.md` | Gate check details, pass/fail specifics, deviation justifications |
+| `FIX-BRIEF-*.md` | What failed, root cause analysis, fix applied |
+| `REVIEW-FEEDBACK-*.md` | Human reviewer comments, approval/rejection reasons, revision requests |
+| `ASSETS/` | Final asset content for qualitative assessment of what shipped |
+
+Scan order: STATE.md first (quantitative summary), then VERIFICATION.md and FIX-BRIEF (failure details), then REVIEW-FEEDBACK (human signal), then BRIEF.md (strategy context).

package/references/measurement-template.md

@@ -0,0 +1,48 @@
+# Measurement Data Template
+
+Paste your analytics data in any of these formats: CSV, Markdown table, or plain text.
+Group your data into these categories:
+
+## Traffic Metrics
+
+| Metric | Value |
+|--------|-------|
+| Page views | |
+| Sessions | |
+| Unique visitors | |
+| Referral sources (top 5) | |
+
+## Engagement Metrics
+
+| Metric | Value |
+|--------|-------|
+| Average time on page | |
+| Bounce rate | |
+| Pages per session | |
+| Scroll depth (if available) | |
+
+## Conversion Metrics
+
+| Metric | Value |
+|--------|-------|
+| Primary conversions (signups, purchases, etc.) | |
+| Conversion rate | |
+| Revenue (if applicable) | |
+| Pipeline value (if applicable) | |
+
+## Channel Attribution Data
+
+| Channel | Touches | Conversions | Revenue |
+|---------|---------|-------------|---------|
+| | | | |
+
+## Campaign-Specific Metrics
+
+| Metric | Target | Actual |
+|--------|--------|--------|
+| [outcome metric from brief] | | |
+| [output metric 1] | | |
+| [output metric 2] | | |
+
+> You can paste raw CSV, a screenshot transcript, or any structured data.
+> The AI will map columns to the expected fields and ask for clarification on unmapped data.

package/references/meta-gate-evaluation.md

@@ -0,0 +1,169 @@
+# Meta-Gate Evaluation Reference
+
+> This file is loaded by verify.md Step 4c via @-syntax. All meta-gates are Tier 2 advisory -- they produce findings in the report but do NOT block verification.
+
+## Usage
+
+Meta-gates operate at the **portfolio level**, not on individual assets. They evaluate the campaign mix, scheduling, thematic alignment, and learning plans across all active campaigns.
+
+**Data collection:** Run the following command to get all campaign states:
+
+```bash
+node ${CLAUDE_PLUGIN_ROOT}/bin/ttm-tools.cjs campaign list --raw
+```
+
+Additional data sources: `.marketing/CALENDAR.md`, `.marketing/CAMPAIGNS/<slug>/BRIEF.md`
+
+## Structured Output Format
+
+Each meta-gate evaluation MUST produce output in this format:
+
+- **Gate:** [Gate Name] (META-XX)
+- **Tier:** 2 (Advisory)
+- **Result:** [PASS|WARN|FAIL]
+- **Summary:** [One-sentence summary]
+- **Evidence:** [Data supporting the finding]
+- **Recommendation:** [Suggested action if WARN or FAIL; "None" if PASS]
+
+---
+
+## META-01: Portfolio Balance
+
+**What it checks:** Whether the active campaign mix covers all funnel stages (awareness, consideration, conversion, retention) and does not over-index on any single stage.
+
+**Tier:** 2 (Advisory)
+
+**Data source:** `campaign list --raw` output + each campaign's BRIEF.md (funnel stage field)
+
+### Evaluation Criteria
+
+**Check 1: Funnel Coverage**
+
+Count the distinct funnel stages represented across all active campaigns.
+
+- **PASS:** 3 or more funnel stages covered (e.g., awareness + consideration + conversion)
+- **WARN:** 2 funnel stages covered
+- **FAIL:** 1 funnel stage covered (all campaigns targeting the same stage)
+
+**Check 2: Channel Diversity**
+
+Count the distinct channels used across all active campaigns.
+
+- **PASS:** 3 or more distinct channels
+- **WARN:** 2 distinct channels
+- **FAIL:** 1 channel only (single-channel dependency)
+
+### Aggregation
+
+- If ALL checks PASS: META-01 = PASS
+- If ANY check is WARN and none FAIL: META-01 = WARN
+- If ANY check is FAIL: META-01 = FAIL
+
+---
+
+## META-02: Calendar Collision
+
+**What it checks:** Scheduling conflicts between campaigns -- overlapping launch dates, competing for the same audience segment simultaneously, or conflicting messages in market at the same time.
+
+**Tier:** 2 (Advisory)
+
+**Data source:** `campaign list --raw` output + `.marketing/CALENDAR.md` + each campaign's BRIEF.md (launch date, audience segment)
+
+### Evaluation Criteria
+
+**Check 1: Launch Overlap**
+
+Compare launch dates across all active and scheduled campaigns.
+
+- **PASS:** No 2 campaigns launch within a 3-day window
+- **WARN:** 2 campaigns launch in the same week (but not within 3 days)
+- **FAIL:** 3 or more campaigns launch in the same week
+
+**Check 2: Audience Collision**
+
+Compare target audience segments across campaigns launching in the same 2-week window.
+
+- **PASS:** Different audience segments (no overlap)
+- **WARN:** Same audience segment but different channels
+- **FAIL:** Same audience segment AND same channel in the same 2-week window
+
+### Aggregation
+
+- If ALL checks PASS: META-02 = PASS
+- If ANY check is WARN and none FAIL: META-02 = WARN
+- If ANY check is FAIL: META-02 = FAIL
+
+---
+
+## META-03: Theme Consistency
+
+**What it checks:** Whether active campaigns align with the quarterly theme defined in CALENDAR.md. Flags campaigns that drift from the strategic narrative.
+
+**Tier:** 2 (Advisory)
+
+**Data source:** `.marketing/CALENDAR.md` (quarterly theme section) + each campaign's BRIEF.md
+
+### Evaluation Criteria
+
+**Check 1: Theme Alignment**
+
+Compare each active campaign's messaging theme against the current quarter's theme in CALENDAR.md.
+
+- **PASS:** Campaign BRIEF.md contains explicit reference to the quarterly theme or directly supports it
+- **WARN:** Campaign theme is adjacent to the quarterly theme but does not explicitly reference it
+- **FAIL:** Campaign contradicts or ignores the quarterly theme without documented rationale
+
+### Aggregation
+
+- If ALL campaigns PASS: META-03 = PASS
+- If ANY campaign is WARN and none FAIL: META-03 = WARN
+- If ANY campaign is FAIL: META-03 = FAIL
+
+---
+
+## META-04: Learning Plan
+
+**What it checks:** Whether every campaign has a measurement plan and a learning hypothesis. Flags campaigns that ship without defining what success looks like or what the team will learn.
+
+**Tier:** 2 (Advisory)
+
+**Data source:** Each campaign's BRIEF.md (outcome metric, measurement plan, hypothesis sections)
+
+### Evaluation Criteria
+
+**Check 1: Measurement Plan**
+
+Verify each active campaign's BRIEF.md defines a complete measurement plan.
+
+- **PASS:** Campaign has outcome metric + numeric target + measurement time window
+- **WARN:** Campaign has outcome metric but is missing target value or measurement window
+- **FAIL:** Campaign has no outcome metric defined
+
+**Check 2: Testable Hypothesis**
+
+Verify each active campaign's BRIEF.md includes a testable hypothesis.
+
+- **PASS:** Campaign defines a specific, falsifiable hypothesis (e.g., "We believe [action] will produce [result] because [reason]")
+- **WARN:** Campaign states a goal but does not frame it as a testable hypothesis
+- **FAIL:** Campaign only has output targets (impressions, clicks) with no hypothesis about outcomes
+
+### Aggregation
+
+- If ALL checks PASS: META-04 = PASS
+- If ANY check is WARN and none FAIL: META-04 = WARN
+- If ANY check is FAIL: META-04 = FAIL
+
+---
+
+## Summary Table Format
+
+After evaluating all 4 meta-gates, present results in a summary table:
+
+| # | Meta-Gate | Result | Key Finding |
+|---|-----------|--------|-------------|
+| 1 | Portfolio Balance (META-01) | [PASS/WARN/FAIL] | [one-line summary] |
+| 2 | Calendar Collision (META-02) | [PASS/WARN/FAIL] | [one-line summary] |
+| 3 | Theme Consistency (META-03) | [PASS/WARN/FAIL] | [one-line summary] |
+| 4 | Learning Plan (META-04) | [PASS/WARN/FAIL] | [one-line summary] |
+
+**All meta-gates are advisory.** They appear in the verification report's meta-gate section but do not affect the overall PASS/FAIL result of asset verification.

package/references/positioning-check-report.md

@@ -0,0 +1,197 @@
+# Positioning Check Report Format
+
+## Usage
+
+Referenced by `workflows/reference-mgmt/positioning-check.md` via @-syntax.
+Defines the audit report format, drift categorization, trend comparison logic,
+and cross-reference handling for accepted deviations.
+
+---
+
+## Drift Categories
+
+Drift is evaluated using GATE-01's 3 checks. Each check maps to a category:
+
+| Check # | Category | PASS Criteria | WARN Criteria | FAIL Criteria |
+|---------|----------|---------------|---------------|---------------|
+| 1 | Differentiator Alignment | Asset restates or naturally extends primary differentiator | Asset is neutral -- neither reinforces nor contradicts | Asset introduces a different/competing claim |
+| 2 | Proof Point Sourcing | All factual claims backed by POSITIONING.md proof points | Some claims present but not all sourced | Claims contradict or fabricate proof points |
+| 3 | Must-Not-Say Compliance | No terms from must-not-say list appear | Terms appear in non-customer-facing context | Must-not-say terms in customer-facing copy |
+
+---
+
+## Bleeding Analysis
+
+Bleeding occurs when must-not-say terms from POSITIONING.md appear in **customer-facing** materials. This is distinct from general must-not-say drift -- non-customer-facing usage (internal briefs, planning docs) is a WARN, but customer-facing usage represents positioning "bleeding" into territory the brand explicitly avoids.
+
+### Asset Type Classification
+
+Classify each asset as customer-facing or non-customer-facing based on its file path and content type:
+
+| Asset Type | Classification | Examples |
+|------------|---------------|----------|
+| Landing pages, blog posts, ad copy, social posts, email campaigns | Customer-facing | Assets intended for external audience consumption |
+| Internal briefs, research docs, planning notes, strategy docs | Non-customer-facing | Assets used internally for planning and alignment |
+
+When asset type is ambiguous, classify as customer-facing (conservative default).
+
+### Bleeding Severity
+
+| Check 3 Result | Asset Type | Bleeding Status | Severity |
+|----------------|-----------|-----------------|----------|
+| FAIL | Customer-facing | BLEEDING | Critical -- must-not-say term reaching external audience |
+| WARN | Non-customer-facing | NOT BLEEDING | Advisory -- internal usage, lower risk |
+| PASS | Any | CLEAN | No must-not-say terms found |
+
+---
+
+## Per-Asset Drift Calculation
+
+Per-asset drift percentage = (WARN checks + FAIL checks) / total checks evaluated * 100
+
+- 3 checks evaluated per asset (one per GATE-01 sub-check)
+- PASS = 0 drift points, WARN = 1 drift point, FAIL = 1 drift point
+- 0% = fully on-positioning, 33% = one check drifted, 67% = two checks drifted, 100% = fully off-positioning
+
+---
+
+## Aggregate Drift Calculation
+
+Aggregate drift % = total drift points across all assets / (total assets * 3) * 100
+
+Where:
+- total drift points = count of all WARN + FAIL results across all assets and all 3 checks
+- total assets * 3 = maximum possible drift points (3 checks per asset)
+
+Example: 5 assets, 3 WARN findings, 1 FAIL finding = 4 / 15 * 100 = 26.7% aggregate drift
+
+---
+
+## Trend Comparison Logic
+
+When a prior audit entry exists in `.marketing/DRIFT-LOG.md`:
+
+1. Find the most recent row in the Audit Trail table where Event = `audit`
+2. Parse the Details column to extract the prior aggregate drift percentage
+   - Expected format: `"Nd audit: X% drift, Y findings across Z assets"`
+   - Extract X as the prior drift percentage
+3. Calculate delta: current aggregate drift % - prior aggregate drift %
+4. Determine trend arrow:
+   - Delta > +5%: UP arrow (drift increasing -- worse)
+   - Delta < -5%: DOWN arrow (drift decreasing -- better)
+   - Delta between -5% and +5%: STABLE (no significant change)
+
+If no prior audit entry exists: display "First audit -- no trend data available."
+
+---
+
+## Cross-Reference Logic
+
+For each campaign in the audit window:
+
+1. Read `.marketing/CAMPAIGNS/<slug>/DEVIATIONS.md` if it exists
+2. Filter for rows where Gate = `positioning_drift` (GATE-01 deviations)
+3. These are assets where drift was previously detected but explicitly accepted by the user
+4. Include in the "Accepted Deviations" section of the report
+5. Accepted deviations still count toward the aggregate drift calculation (they represent
+   real drift, just intentionally accepted drift)
+
+---
+
+## Report Template
+
+Present the audit report in this exact format:
+
+```
+========================================
+takeToMarket > POSITIONING AUDIT REPORT
+========================================
+
+Audit Window: last ${WINDOW}
+Assets Audited: ${ASSET_COUNT} across ${CAMPAIGN_COUNT} campaigns
+Date: ${ISO_DATE}
+
+----------------------------------------
+AGGREGATE DRIFT: ${AGGREGATE_DRIFT}%  ${TREND_ARROW}
+----------------------------------------
+${TREND_DETAIL}
+
+## Per-Asset Results
+
+| # | Asset | Campaign | Differentiator | Proof Points | Must-Not-Say | Drift % |
+|---|-------|----------|----------------|--------------|--------------|---------|
+| 1 | ${ASSET_NAME} | ${CAMPAIGN_SLUG} | ${CHECK_1} | ${CHECK_2} | ${CHECK_3} | ${DRIFT_PCT}% |
+| ... | ... | ... | ... | ... | ... | ... |
+
+## Drift Type Breakdown
+
+| Category | Count | % of Total Findings |
+|----------|-------|---------------------|
+| Differentiator Alignment | ${DIFF_COUNT} | ${DIFF_PCT}% |
+| Proof Point Sourcing | ${PROOF_COUNT} | ${PROOF_PCT}% |
+| Must-Not-Say Violations | ${MNS_COUNT} | ${MNS_PCT}% |
+
+## Bleeding Analysis
+
+Must-not-say terms that have bled into customer-facing materials:
+
+| # | Asset | Campaign | Term Found | Context | Severity |
+|---|-------|----------|------------|---------|----------|
+| 1 | ${ASSET_NAME} | ${CAMPAIGN_SLUG} | "${TERM}" | "${SURROUNDING_CONTEXT}" | Critical |
+| ... | ... | ... | ... | ... | ... |
+
+**Bleeding count:** ${BLEEDING_COUNT} of ${MNS_VIOLATION_COUNT} must-not-say violations are in customer-facing materials
+**Bleeding rate:** ${BLEEDING_RATE}% of must-not-say violations have bled into customer-facing territory
+
+${IF_NO_BLEEDING}No must-not-say terms found in customer-facing materials. Positioning boundaries are holding.${END_IF}
+${IF_BLEEDING}Customer-facing assets contain must-not-say terms. These should be prioritized for /ttm-fix as they represent active positioning leakage to your audience.${END_IF}
+
+## Findings Detail
+
+For each WARN or FAIL result, show:
+
+### [ASSET_NAME] (${CAMPAIGN_SLUG}) -- ${CATEGORY} [${RESULT}]
+
+**Evidence:** "[exact quote or description from asset]"
+**Reference:** "[corresponding text from POSITIONING.md]"
+**Recommendation:** [specific action to resolve]
+
+## Accepted Deviations
+
+Previously accepted positioning deviations found in campaign DEVIATIONS.md files:
+
+| Asset | Campaign | Gate | Justification | Run |
+|-------|----------|------|---------------|-----|
+| ${ASSET} | ${SLUG} | ${GATE} | ${JUSTIFICATION} | ${RUN} |
+
+If no accepted deviations: "No previously accepted positioning deviations found."
+
+## Trend Comparison
+
+${TREND_TABLE_OR_FIRST_AUDIT_MESSAGE}
+
+If prior audit exists:
+| Metric | Prior Audit | Current Audit | Delta |
+|--------|-------------|---------------|-------|
+| Aggregate Drift | ${PRIOR_PCT}% | ${CURRENT_PCT}% | ${DELTA}% ${ARROW} |
+| Assets Audited | ${PRIOR_COUNT} | ${CURRENT_COUNT} | -- |
+| Window | ${PRIOR_WINDOW} | ${CURRENT_WINDOW} | -- |
+
+## Recommendations
+
+- If aggregate drift > 30%: "Aggregate drift exceeds 30%. Consider running /ttm-positioning-shift to evaluate whether your positioning needs updating."
+- If aggregate drift > 0% and <= 30%: "Some drift detected. Run /ttm-fix on specific assets with FAIL results to bring them back on-positioning."
+- If aggregate drift = 0%: "All assets are on-positioning. No action needed."
+- For any FAIL results: "Assets with FAIL results should be addressed via /ttm-fix [campaign-slug]."
+```
+
+---
+
+## Status Thresholds
+
+| Aggregate Drift % | Status | Recommended Action |
+|--------------------|--------|-------------------|
+| 0% | On-Positioning | No action needed |
+| 1-15% | Minor Drift | Fix individual assets via /ttm-fix |
+| 16-30% | Moderate Drift | Review positioning strategy, fix flagged assets |
+| 31%+ | Significant Drift | Run /ttm-positioning-shift to evaluate positioning changes |