@friedbotstudio/create-baseline 0.6.0 → 0.7.0

package/src/seed.template.md

@@ -247,7 +247,7 @@ Each vendored shared global ships with its own `LICENSE` + `NOTICE` alongside th
 
 - `chore` — for tasks with no failing-test-driven code change (documentation, governance counts, vendored-skill content updates, configuration, formatting, typo fixes, dependency bumps, skill consolidations). Skips `/scenario` and `/implement` — there is nothing to drive with a failing test. Runs the edits directly, then conditionally invokes `simplify` / `integrate` / `document` based on what the diff touches (each has explicit triggers in the chore skill body). `verify`, `archive`, and `/grant-commit` + `/commit` always run. Chore is a stripped-down pipeline, **not** a bypass — silent skips of triggered conditional phases are forbidden; the end-of-chore summary documents every skip rationale. Tasks that need a real failing test route to `/tdd` or higher instead.
 
-### §4.4 Commands (4) — structurally user-only
+### §4.4 Commands (6) — structurally user-only
 
 Files at `.claude/commands/<name>.md`. Commands differ from skills in exactly one way: **Claude cannot invoke them via the Skill tool.** A command is a button only a human can press.
 
@@ -258,8 +258,9 @@ Files at `.claude/commands/<name>.md`. Commands differ from skills in exactly on
 | `grant-commit` | Opens a 5-minute consent window for `git commit` on a protected branch. Writes `.claude/state/commit_consent`. Enforced by `git_commit_guard`. |
 | `grant-push` | Opens a 5-minute consent window for `git push` on a protected branch. Writes `.claude/state/push_consent`. Enforced by `git_commit_guard`. Not a workflow-phase gate — a runtime consent for the branch-aware policy (§11). |
 | `init-project` | One-time bootstrap. Detects stack, proposes `.claude/project.json` (test cmd, lint cmd, TDD globs, destructive patterns, artifact required sections, swarm config). Flips `configured: true`. |
+| `init-project-doctor` | Detects baseline drift — missing/invalid `.claude/workflows.jsonl`, schema/invariant violations, four-way Article IV / §18 mirror drift, and (advisory) shipped-tooling files placed outside `.claude/`. Interactive: presents each violation via `AskUserQuestion` and applies the named fix on confirmation. |
 
-**Adding a sixth command requires answering yes to both:** "does a human need to press this?" and "is 'user-only via frontmatter flag' too weak a guarantee?" Otherwise make it a skill.
+**Adding a seventh command requires answering yes to both:** "does a human need to press this?" and "is 'user-only via frontmatter flag' too weak a guarantee?" Otherwise make it a skill.
 
 ### §4.5 MCP servers (3)
 
@@ -338,7 +339,7 @@ Phases are fixed ordering; `/triage` picks the entry and may mark phases as exce
 
 ## §6 — Consent model
 
-**Four consent gates + one bootstrap gate.** All are slash commands, not skills. Commands live in `.claude/commands/`; Claude cannot invoke them via the Skill tool. The guarantee is structural (file location), not flag-based. Three of the four gates are workflow-phase gates (A: `/approve-spec`, B: `/approve-swarm`, C: `/grant-commit`); the fourth (`/grant-push`) is a Bash-time consent for the branch-aware push policy in §11.
+**Four consent gates + one bootstrap + one doctor.** All are slash commands, not skills. Commands live in `.claude/commands/`; Claude cannot invoke them via the Skill tool. The guarantee is structural (file location), not flag-based. Three of the four gates are workflow-phase gates (A: `/approve-spec`, B: `/approve-swarm`, C: `/grant-commit`); the fourth (`/grant-push`) is a Bash-time consent for the branch-aware push policy in §11. The bootstrap is `/init-project`; the doctor is `/init-project doctor` (drift detector + repairer for `.claude/workflows.jsonl` + the §18 / Article IV four-way mirror; see §18.7).
 
 | Gate | When it fires | Unlocks |
 |---|---|---|
@@ -598,3 +599,147 @@ The audit at `.claude/skills/audit-baseline/audit.sh` consumes `manifest.owners.
 The audit also verifies constitutional citation: CLAUDE.md SHALL contain the literal string "Article XI" and a reference to the manifest, and `docs/init/seed.md` SHALL contain "§17" and a manifest reference. Missing citations trigger FAIL with `CLAUDE.md missing Article XI citation` or `seed.md missing §17 citation`.
 
 This provenance system is intentionally minimal: the manifest tracks shipped-file hashes; the frontmatter declares per-skill ownership; the audit reconciles the two against on-disk reality. Cryptographic supply-chain attestation, signed lock files, and per-skill aggregate merkle hashes are non-goals; the per-file `manifest.files` map already covers every file in every skill directory. A future `npx @friedbotstudio/create-baseline upgrade` subcommand will consume `manifest.owners.skills` + `manifest.files` to safely re-overlay baseline-owned files while leaving user-added skills and locally-customized baseline skills untouched — that subcommand is out of scope here.
+
+---
+
+## §18 — Workflow definitions and Article IV invariants
+
+### 18.1 Source of truth
+
+`.claude/workflows.jsonl` is the canonical source for every workflow this baseline can execute. The file holds one Track record per line (JSONL). It is project-owned and `NEVER_TOUCH` (declared in `src/cli/install.js:NEVER_TOUCH` and `scripts/build-manifest.mjs:NEVER_TOUCH_PATHS`); baseline upgrades preserve user customizations verbatim via `NEVER_TOUCH_PRESERVE`. The shipped baseline overlays the pristine 6-track set from `src/.claude/workflows.template.jsonl` onto fresh installs via `scripts/build-template.sh` Stage 2; existing installs are not touched. The JSON Schema document at `.claude/schemas/workflow-track.v1.json` is referenced by `Track.$schema` and is itself `NEVER_TOUCH`.
+
+`workflows.jsonl` supersedes the hardcoded triage templates (intake-full / spec-entry / tdd-quickfix / chore). Triage reads `workflows.jsonl` at seed time, validates each Track, classifies the user's request, and materializes the chosen Track's DAG into the TaskList. The canonical four tracks shipped in the pristine template are byte-equivalent to the pre-§18 hardcoded templates per spec AC-016 (`tests/byte-equivalent-migration.test.mjs`).
+
+### 18.2 Track schema
+
+A **Track** record has this shape (full definition in `.claude/schemas/workflow-track.v1.json`):
+
+```jsonc
+{
+  "$schema": "./schemas/workflow-track.v1.json",
+  "track_id": "<unique-across-file>",
+  "name": "<short label>",
+  "description": "<paragraph; read by the LLM classifier>",
+  "selectable": true,            // false = sub-track only (referenced via sub_track)
+  "selector_hints": ["<descriptive phrase>", ...],
+  "preconditions": [{"name": "<predicate>", "argument": "<opt>"}, ...],
+  "invariants": ["commits", "requires_spec", ...],
+  "nodes": [Node, ...]
+}
+```
+
+A **Node** is either a `task` (skill invocation or sub-track expansion) or a `selector` (picks one of multiple alternates at runtime):
+
+```jsonc
+{
+  "id": "<unique-within-track>",
+  "type": "task" | "selector",
+  // type=task → exactly one of:
+  "skill": "<skill-or-command-name>",
+  "sub_track": "<another-track_id>",
+  // type=selector → required:
+  "alternates": [Alternate, ...],
+  // shared:
+  "input": "<opt; passed to the skill at invocation>",
+  "invocation_prompt": "<opt; declared-now/used-later — v2 Handlebars+LLM>",
+  "output": "<opt; informational artifact path>",
+  "output_formatter_prompt": "<opt; declared-now/used-later>",
+  "depends_on": ["<predecessor node id>", ...],
+  "blocks": ["<successor node id>", ...],
+  "can_parallel": false,         // true: peers at same dep level dispatch concurrently
+  "needs_user": false,           // true: consent gate; harness yields
+  "activeForm": "<TaskList spinner text>",
+  "metadata": {"phase": "<...>"}
+}
+```
+
+An **Alternate** (inside a selector node):
+
+```jsonc
+{
+  "skill": "<skill-name>",       // XOR with sub_track
+  "sub_track": "<track_id>",     // XOR with skill
+  "preconditions": [Predicate, ...],
+  "description": "<rationale>"
+}
+```
+
+A **Predicate** (track-level and alternate-level):
+
+```jsonc
+{
+  "name": "<v1-vocabulary>",
+  "argument": "<opt; e.g., '3' for min_components>"
+}
+```
+
+### 18.3 Article IV invariants (I1..I11)
+
+Every Track in `workflows.jsonl` SHALL satisfy these invariants. Validation runs at three points: install/upgrade time (audit-baseline), triage time (LLM-driven selector), and harness time (per-node before dispatch).
+
+- **I1.** Unique `track_id` across the file.
+- **I2.** Unique `node.id` within a track.
+- **I3.** `type=task` nodes carry exactly one of `{skill, sub_track}`. `type=selector` nodes carry non-empty `alternates[]`.
+- **I4.** Every `depends_on` and `blocks` reference resolves to a `node.id` in the same track.
+- **I5.** The dependency DAG is acyclic.
+- **I6.** Tracks declaring the `commits` invariant SHALL include a `needs_user: true` `grant-commit` node ordered before the node with `skill: "commit"`.
+- **I7.** Every `sub_track` reference resolves to a Track with `selectable: false`.
+- **I8.** Every `skill:` reference resolves to a known invokable — skill in `EXPECTED_SKILLS ∪ project.json additions.skills`, OR consent-gate command in `.claude/commands/` (e.g., `approve-spec`, `grant-commit`, `approve-swarm`).
+- **I9.** `needs_user: true` nodes appear in dependency order before any node that depends on their consent.
+- **I10.** A selector node's alternates SHALL share the same shape (all skill, or all sub_track) — they're interchangeable in the DAG.
+- **I11.** Every `Predicate.name` resolves to a known v1 predicate (see §18.4).
+
+### 18.4 Predicate vocabulary (v1)
+
+The closed set of declarative predicates that may appear in Track or Alternate `preconditions[]`:
+
+| Predicate | Argument | Evaluates true when |
+|---|---|---|
+| `requires_git` | — | `git rev-parse --is-inside-work-tree` exits 0 at the project root. |
+| `requires_user_override` | `<value>` | The user explicitly named this alternate in conversation (e.g., "use solo"). |
+| `requires_min_components` | `<int>` | The approved spec has at least N C4 Components. |
+| `requires_phase_completed` | `<phase>` | The named phase appears in `workflow.json → completed`. |
+| `requires_skill_present` | `<skill_id>` | The named skill exists in `EXPECTED_SKILLS ∪ additions.skills`. |
+
+Adding a new predicate is a constitutional change: update this section, update `src/cli/workflows-validator-predicates.js`, and update the corresponding seed.template.md mirror.
+
+### 18.5 `invocation_prompt` / `output_formatter_prompt` — declared, deferred
+
+Both fields are part of the v1 Node schema and validated at parse time. They are **not actuated in v1** — the harness ignores them. They are declared now to lock the schema shape so future Track records can carry them without a schema bump. The v2 actuation plan: Handlebars-style templates with LLM interpolation, allowing per-track UX customization of the invocation phrasing and the post-skill output formatting. Until v2 ships, populating these fields is allowed but inert.
+
+### 18.6 Migration from pre-§18 workflow.json
+
+An in-flight `.claude/state/workflow.json` written by a pre-§18 baseline (carries `entry_phase` field, no `track_id`) is one-shot-migrated by the harness preflight before the workflow loads. The canonical map:
+
+| `entry_phase` (pre-§18) | `track_id` (post-§18) |
+|---|---|
+| `intake` | `intake-full` |
+| `spec` | `spec-entry` |
+| `tdd` | `tdd-quickfix` |
+| `chore` | `chore` |
+
+`completed[]` is remapped from phase names to node ids; the canonical tracks are designed so most phase names equal the corresponding node id (identity remap), with the exception of selector wrappers (e.g., `implementation` in intake-full wraps the swarm-vs-tdd selection). The migrator initializes `skipped_alternates: []` and refreshes `updated_at`. Idempotent: re-running on an already-migrated workflow.json is a no-op. Unmapped `entry_phase` halts with a named error; the user restarts via `/triage`.
+
+Migrator implementation: `src/cli/workflow-migrator.js` exports `migrateWorkflowJsonInPlace(filePath)`.
+
+### 18.7 Lifecycle: install, upgrade, doctor
+
+- **Fresh install.** `scripts/build-template.sh` overlays `src/.claude/workflows.template.jsonl` → `obj/template/.claude/workflows.jsonl` at Stage 2, and the pristine schemas/ directory bulk-rsyncs at Stage 1. The CLI install copies both into the consumer target. Result: every fresh install has `<target>/.claude/workflows.jsonl` with the canonical 4 selectable + 2 sub-track set.
+
+- **Upgrade.** Both `.claude/workflows.jsonl` and `.claude/schemas/workflow-track.v1.json` are `NEVER_TOUCH`. The merge flow returns `NEVER_TOUCH_PRESERVE` for them on every upgrade; user customizations (added tracks, modified nodes, per-project additions like `cli-copy-review`) survive verbatim.
+
+- **Doctor.** `/init-project doctor` (new sub-command) detects drift: missing `workflows.jsonl`, schema/invariant violations, four-way mirror drift between seed.md §18 / src/seed.template.md §18 / CLAUDE.md Article IV / src/CLAUDE.template.md Article IV, and (advisory) shipped-tooling files placed outside `.claude/` per the convention codified at §3.
+
+### 18.8 Cross-references
+
+- `CLAUDE.md Article IV` — phase-ordering rules; binding on every commit-producing track.
+- `CLAUDE.md Article VII` — git rules; relevant to the `requires_git` precondition.
+- `seed.md §3` — directory structure convention (tooling lives under `.claude/`).
+- `seed.md §17` — skill provenance (separate concern; workflows.jsonl is project-owned, not baseline-owned).
+- `.claude/workflows.jsonl` — this project's live tracks.
+- `.claude/schemas/workflow-track.v1.json` — JSON Schema referenced by `Track.$schema`.
+- `src/cli/workflows-validator.js` — validator orchestration.
+- `src/cli/workflows-validator-invariants.js` — invariant checks I1–I11.
+- `src/cli/workflows-validator-predicates.js` — predicate vocabulary.
+- `src/cli/workflow-migrator.js` — pre-§18 → post-§18 migrator.
+- `src/cli/track-tasklist-materializer.js` — Track → TaskList shape.

package/obj/template/.claude/skills/google-analytics/SKILL.md

@@ -1,129 +0,0 @@
----
-name: google-analytics
-description: Comprehensive Google Analytics 4 guide covering property setup, events, custom events, recommended events, custom dimensions, user tracking, audiences, reporting, BigQuery integration, gtag.js implementation, GTM integration, Measurement Protocol, DebugView, privacy compliance, and data management. Use when working with GA4 implementation, tracking, analysis, or any GA4-related tasks.
----
-
-# Google Analytics 4 Complete Guide
-
-## Overview
-
-Google Analytics 4 (GA4) is Google's event-based analytics platform for measuring user interactions across websites and applications. Every user interaction is tracked as an event with associated parameters, providing flexible cross-platform measurement.
-
-## When to Use This Skill
-
-Invoke this skill for any GA4-related task:
-
-- Setting up GA4 properties, data streams, and Measurement IDs
-- Installing GA4 via gtag.js, GTM, or CMS plugins
-- Implementing event tracking (automatic, recommended, custom, ecommerce)
-- Creating custom dimensions, audiences, and reports
-- Exporting data to BigQuery for SQL analysis
-- Server-side tracking via Measurement Protocol
-- User ID and cross-device tracking
-- Privacy compliance, Consent Mode, and GDPR/CCPA
-- Testing and debugging with DebugView
-
-## Quick Start
-
-1. **Create property:** analytics.google.com -> Admin -> Create -> Property
-2. **Create data stream:** Add web stream, note Measurement ID (G-XXXXXXXXXX)
-3. **Install tracking** (choose one):
-   - **GTM (recommended):** Install container, create Google Tag with Measurement ID, trigger on All Pages, publish
-   - **gtag.js direct:**
-     ```html
-     <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
-     <script>
-       window.dataLayer = window.dataLayer || [];
-       function gtag(){dataLayer.push(arguments);}
-       gtag('js', new Date());
-       gtag('config', 'G-XXXXXXXXXX');
-     </script>
-     ```
-4. **Verify:** Enable GA Debugger extension, check Admin -> DebugView for session_start, page_view
-5. **Send custom events:**
-   ```javascript
-   gtag('event', 'button_click', { button_name: 'Subscribe', button_location: 'header' });
-   ```
-
-## Decision Tree: Which Reference Do I Need?
-
-```
-What are you trying to do?
-
-Setting up GA4 for the first time?         -> references/setup.md
-Understanding how events work?              -> references/events-fundamentals.md
-Implementing standard tracking events?      -> references/recommended-events.md
-Creating business-specific custom events?   -> references/custom-events.md
-Making parameters appear in reports?        -> references/custom-dimensions.md
-Implementing User ID / cross-device?        -> references/user-tracking.md
-Building audiences for remarketing?         -> references/audiences.md
-Analysing data in GA4 reports?              -> references/reporting.md
-Exporting to BigQuery for SQL analysis?     -> references/bigquery.md
-Installing via gtag.js directly?            -> references/gtag.md
-Setting up GA4 in Google Tag Manager?       -> references/gtm-integration.md
-Sending events from server/backend?         -> references/measurement-protocol.md
-Testing and debugging implementation?       -> references/debugview.md
-Implementing GDPR/Consent Mode?             -> references/privacy.md
-Configuring Admin settings?                 -> references/data-management.md
-```
-
-## Core Concepts
-
-### Event-Based Model
-
-GA4 tracks everything as events in four categories:
-
-| Category | Description | Examples |
-|----------|-------------|----------|
-| Automatic | Fire without configuration | session_start, first_visit |
-| Enhanced Measurement | Toggle on/off in settings | scroll, click, file_download |
-| Recommended | Google-defined with standard parameters | purchase, login, sign_up |
-| Custom | Business-specific tracking | demo_requested, trial_started |
-
-### Key Limits
-
-| Limit | Value |
-|-------|-------|
-| Event names per property | 500 distinct |
-| Parameters per event | 25 |
-| Event name length | 40 characters |
-| Parameter name/value length | 40 / 100 characters |
-| Custom dimensions (event/user/item) | 50 / 25 / 10 |
-| Audiences per property | 100 |
-
-### Measurement ID
-
-- Format: `G-XXXXXXXXXX` (G- prefix + 10 alphanumeric characters)
-- Location: Admin -> Data Streams -> Web Stream
-- Used in: gtag.js config, GTM tags, Measurement Protocol
-
-## Common Workflows
-
-### Ecommerce Tracking
-
-1. Review [recommended events](references/recommended-events.md) for the purchase funnel: view_item -> add_to_cart -> begin_checkout -> purchase
-2. Structure items array (required: item_id OR item_name; recommended: price, quantity, item_category)
-3. Test with [DebugView](references/debugview.md), then register custom item parameters as [custom dimensions](references/custom-dimensions.md)
-
-### Cross-Device Tracking
-
-1. Implement [User ID](references/user-tracking.md) and configure Reporting Identity (Admin -> Data Settings)
-2. Set [user properties](references/custom-dimensions.md) and build [cross-device audiences](references/audiences.md)
-
-### GDPR Compliance
-
-1. Set up [Consent Mode](references/privacy.md) with default denied state
-2. Integrate with CMP (OneTrust, Cookiebot, etc.), update consent on user acceptance
-3. Test consent implementation with [DebugView](references/debugview.md)
-
-### Custom Reports
-
-1. Understand available data in [reporting](references/reporting.md)
-2. Register custom parameters as [dimensions](references/custom-dimensions.md), create Explorations
-3. For unsampled data, export to [BigQuery](references/bigquery.md)
-
-## Best Practices
-
-- **Naming:** Use snake_case, be descriptive and action-oriented, keep under 40 characters, avoid generic names
-- **Implementation order:** Enhanced Measurement -> recommended events -> custom events -> custom dimensions
-- **Data quality:** Separate test/production properties, set up internal traffic filters from day one, document all custom events, audit regularly with DebugView, export to BigQuery for backup

package/obj/template/.claude/skills/google-analytics/references/audiences.md

@@ -1,389 +0,0 @@
-# GA4 Audiences and Segmentation
-
-Expert guidance for creating and managing audiences for analysis, remarketing, and personalisation.
-
-## Overview
-
-Audiences in GA4 allow creation of user segments for analysis, remarketing, and personalisation based on dimensions, metrics, and events. Audiences can be exported to Google Ads for targeting and used in GA4 reports for analysis.
-
-## Accessing Audiences
-
-**Path:** Admin -> Audiences
-
-**Available Actions:**
-- View all audiences
-- Create new audiences
-- Edit existing audiences
-- View audience membership
-
-## Predefined Audiences
-
-GA4 includes template audiences:
-
-| Audience | Description |
-|----------|-------------|
-| All Users | All users in selected timeframe |
-| Purchasers | Users who completed purchase (30 days) |
-| New Users | First-time visitors |
-| Returning Users | Repeat visitors |
-| Recent Users | Active in last 7 days |
-
-### Activating Predefined Audiences
-
-1. Admin -> Audiences -> Create Audience
-2. Select suggested template
-3. Customise conditions if needed
-4. Save audience
-
-## Creating Custom Audiences
-
-### Basic Process
-
-1. Admin -> Audiences -> New Audience
-2. Choose method:
-   - Start from scratch
-   - Use suggested template
-   - Create predictive audience
-3. Configure audience:
-   - Name: Descriptive (e.g., "High-Value Shoppers")
-   - Description: Optional notes
-   - Membership duration: 1-540 days
-4. Add conditions
-5. Preview size
-6. Save
-
-### Condition Types
-
-#### Dimension Filters
-
-Filter by user or event attributes:
-
-```
-country == "United States"
-device_category == "mobile"
-platform == "web"
-```
-
-**Available Dimensions:**
-- User: city, country, device_category, platform
-- Event: event_name, page_location, item_id
-- Custom: Any registered custom dimensions
-
-#### Metric Filters
-
-Filter by quantitative measures:
-
-```
-totalRevenue > 100
-sessionCount >= 3
-engagementTime > 60
-```
-
-**Available Metrics:**
-- Event count
-- Session count
-- Revenue
-- Engagement time
-- Conversion count
-
-#### Event Conditions
-
-Include/exclude based on events:
-
-**Include users who:**
-- Have triggered specific event
-- Have NOT triggered event
-- Triggered event with specific parameters
-
-**Example:** Users who triggered `purchase` with `value > 50`
-
-#### Sequence Conditions
-
-Build audiences based on event order:
-
-**Example:** Users who:
-1. Viewed product (view_item)
-2. Added to cart (add_to_cart)
-3. Did NOT complete purchase (within 7 days)
-
-### Membership Duration
-
-| Duration | Use Case |
-|----------|----------|
-| 1-7 days | Short campaigns |
-| 30-90 days | Remarketing |
-| 540 days | Lifetime segments |
-
-**How it works:**
-- User enters when conditions met
-- Stays for duration period
-- Exits after duration (unless conditions still met)
-
-## Audience Examples
-
-### High-Value Customers
-
-```
-Conditions:
-- totalRevenue > 500 (lifetime)
-- purchaseCount >= 3
-
-Membership: 540 days
-```
-
-### Cart Abandoners
-
-```
-Sequence:
-1. add_to_cart (within last 7 days)
-2. Did NOT: purchase
-
-Membership: 7 days
-```
-
-### Engaged Mobile Users
-
-```
-Conditions:
-- deviceCategory == "mobile"
-- sessionCount >= 5 (last 30 days)
-- avgEngagementTime > 60 seconds
-
-Membership: 30 days
-```
-
-### Product Category Viewers
-
-```
-Event Condition:
-- view_item (last 30 days)
-- item_category == "Electronics"
-
-Membership: 30 days
-```
-
-### Geographic Segment
-
-```
-Conditions:
-- country == "United States"
-- region == "California"
-
-Membership: 90 days
-```
-
-### Newsletter Subscribers
-
-```
-Event Condition:
-- sign_up (any time)
-- method == "newsletter"
-
-Membership: 540 days
-```
-
-## Predictive Audiences
-
-GA4 can create audiences based on predicted user behaviour.
-
-### Available Predictions
-
-| Prediction | Description |
-|------------|-------------|
-| Purchase probability | Likelihood to purchase (7 days) |
-| Churn probability | Likelihood to not return (7 days) |
-| Revenue prediction | Expected 28-day revenue |
-
-### Requirements
-
-- 1,000+ users triggering target event (28 days)
-- Sufficient historical data
-- Model quality threshold met
-
-### Creating Predictive Audience
-
-1. Create New Audience
-2. Choose "Predictive"
-3. Select metric (purchase probability, etc.)
-4. Set threshold (e.g., > 50% purchase probability)
-5. Save
-
-### Use Cases
-
-- Target likely purchasers with ads
-- Re-engage likely-to-churn users
-- Focus on high-revenue potential users
-
-## Audience Triggers
-
-### What are Triggers
-
-Actions that fire when user enters audience.
-
-### Supported Actions
-
-- Send event to GA4
-- Create Google Ads remarketing list
-- Send to Google Ads for targeting
-
-### Setup
-
-1. Create audience
-2. In settings, add trigger
-3. Configure action (event name, Ads account)
-4. Save
-
-### Use Cases
-
-- Track when users become high-value
-- Send conversion events to Ads
-- Real-time remarketing lists
-
-## Exporting to Google Ads
-
-### Prerequisites
-
-- Google Ads account linked
-- Admin -> Product Links -> Google Ads Links
-- Minimum audience size met
-
-### Minimum Sizes
-
-| Region | Minimum Users |
-|--------|---------------|
-| Standard | 100 active |
-| EEA/UK | 1,000 active |
-
-### Setup
-
-1. Link Google Ads account
-2. In audience, enable "Ads Personalisation"
-3. Audience appears in Ads within 24-48 hours
-
-### Export Destinations
-
-- Google Ads (remarketing, targeting)
-- Display & Video 360
-- Search Ads 360
-
-## Analysing Audiences
-
-### Viewing Audience Data
-
-**Reports -> Realtime:**
-- Active users in audience
-
-**Reports -> User Acquisition:**
-- How audience members acquired
-
-**Explorations -> Segment Overlap:**
-- Compare audiences
-
-**Explorations -> User Lifetime:**
-- LTV of audience members
-
-### Audience Metrics
-
-| Metric | Description |
-|--------|-------------|
-| Total Users | Current members |
-| New Users (7/30 days) | Recent additions |
-| User Growth | Trend over time |
-
-## Using Audiences in Explorations
-
-### As Segments
-
-1. Open Exploration
-2. Click "+" in Segments
-3. Select audience
-4. Apply to analysis
-
-### Comparing Audiences
-
-1. Add multiple audiences as segments
-2. View side-by-side comparison
-3. Analyse differences
-
-## Limits and Quotas
-
-| Limit | Standard | 360 |
-|-------|----------|-----|
-| Audiences per property | 100 | 400 |
-| Conditions per audience | 10 | 10 |
-| Membership duration max | 540 days | 540 days |
-
-## Common Issues
-
-### Audience Size Too Small
-
-**Causes:**
-- Conditions too restrictive
-- Low traffic volume
-- Date range too narrow
-
-**Solutions:**
-1. Broaden conditions
-2. Increase membership duration
-3. Wait for more traffic
-
-### Audience Not in Google Ads
-
-**Causes:**
-- Below minimum size
-- Link not configured
-- Ads personalisation disabled
-
-**Solutions:**
-1. Check audience size
-2. Verify Google Ads link
-3. Enable Ads Personalisation
-
-### Stale Audience Data
-
-**Cause:** Audiences update with delay
-
-**Solution:** Wait 24-48 hours for updates
-
-## Best Practices
-
-### Naming Conventions
-
-Use clear, descriptive names:
-- "High-Value Customers - $500+"
-- "Cart Abandoners - Last 7 Days"
-- "Newsletter Subscribers"
-
-### Documentation
-
-Document each audience:
-- Purpose
-- Conditions used
-- Expected size
-- Use cases
-
-### Regular Review
-
-- Audit audiences quarterly
-- Remove unused audiences
-- Update conditions as needed
-
-## Quick Reference
-
-### Audience Limits
-
-- Maximum: 100 audiences (standard)
-- Membership: 1-540 days
-- Export minimum: 100 users (1,000 EEA/UK)
-
-### Export Destinations
-
-- Google Ads
-- Display & Video 360
-- Search Ads 360
-
-### Predictive Options
-
-- Purchase probability
-- Churn probability
-- Revenue prediction