mandrel 1.57.0

package/.agents/skills/core/idea-refinement/refinement-criteria.md

@@ -0,0 +1,155 @@
+# Refinement & Evaluation Criteria
+
+Use this rubric during Phase 2 (Evaluate & Converge) to stress-test idea
+directions. Not every criterion applies to every idea — use judgment about which
+dimensions matter most for the specific context.
+
+## Core Evaluation Dimensions
+
+### 1. User Value
+
+The most important dimension. If the value isn't clear, nothing else matters.
+
+**Painkiller vs. Vitamin:**
+
+- **Painkiller:** Solves an acute, frequent problem. Users will actively seek
+  this out. They'll switch from their current solution. Signs: people describe
+  the problem with emotion, they've built workarounds, they'll pay for a
+  solution.
+- **Vitamin:** Nice to have. Makes something marginally better. Users won't go
+  out of their way. Signs: people nod politely, say "that's cool," then don't
+  change behavior.
+
+**Questions to ask:**
+
+- Can you name 3 specific people who have this problem right now?
+- What are they doing today instead? (The real competitor is always the current
+  workaround.)
+- Would they switch from their current approach? What would make them switch?
+- How often do they encounter this problem? (Daily problems > monthly problems)
+- Is this a "pull" problem (users are asking for this) or a "push" problem (you
+  think they should want this)?
+
+**Red flags:**
+
+- "Everyone could use this" — if you can't name a specific user, the value isn't
+  clear
+- "It's like X but better" — marginal improvements rarely drive adoption
+- The problem is real but rare — high intensity but low frequency rarely
+  justifies a product
+
+### 2. Feasibility
+
+Can you actually build this? Not just technically, but practically.
+
+**Technical feasibility:**
+
+- Does the core technology exist and work reliably?
+- What's the hardest technical problem? Is it a known-hard problem or a novel
+  one?
+- Are there dependencies on third parties, APIs, or data sources you don't
+  control?
+- What's the minimum technical stack needed? (If the answer is "a lot," that's a
+  signal.)
+
+**Resource feasibility:**
+
+- What's the minimum team/effort to build an MVP?
+- Does it require specialized expertise you don't have?
+- Are there regulatory, legal, or compliance requirements?
+
+**Time-to-value:**
+
+- How quickly can you get something in front of users?
+- Is there a version that delivers value in days/weeks, not months?
+- What's the critical path? What has to happen first?
+
+**Red flags:**
+
+- "We just need to solve [very hard research problem] first"
+- Multiple dependencies that all need to work simultaneously
+- MVP still requires months of work — likely not minimal enough
+
+### 3. Differentiation
+
+What makes this genuinely different? Not better — _different_.
+
+**Questions to ask:**
+
+- If a user described this to a friend, what would they say? Is that description
+  compelling?
+- What's the one thing this does that nothing else does? (If you can't name one,
+  that's a problem.)
+- Is this differentiation durable? Can a competitor copy it in a week?
+- Is the difference something users actually care about, or just something
+  builders find interesting?
+
+**Types of differentiation (strongest to weakest):**
+
+1. **New capability:** Does something that was previously impossible
+2. **10x improvement:** So much better on a key dimension that it changes
+   behavior
+3. **New audience:** Brings an existing capability to people who were excluded
+4. **New context:** Works in a situation where existing solutions fail
+5. **Better UX:** Same capability, dramatically simpler experience
+6. **Cheaper:** Same thing, lower cost (weakest — easily competed away)
+
+**Red flags:**
+
+- Differentiation is entirely about technology, not user experience
+- "We're faster/cheaper/prettier" without a structural reason why
+- The feature that differentiates is not the feature users care most about
+
+## Assumption Audit
+
+For every idea direction, explicitly list assumptions in three categories:
+
+### Must Be True (Dealbreakers)
+
+Assumptions that, if wrong, kill the idea entirely. These need validation before
+building.
+
+Example: "Users will share their data with us" — if they won't, the entire
+product doesn't work.
+
+### Should Be True (Important)
+
+Assumptions that significantly impact success but don't kill the idea. You can
+adjust the approach if these are wrong.
+
+Example: "Users prefer self-serve over talking to a person" — if wrong, you need
+a different go-to-market, but the core product can still work.
+
+### Might Be True (Nice to Have)
+
+Assumptions about secondary features or optimizations. Don't validate these
+until the core is proven.
+
+Example: "Users will want to share their results with teammates" — a growth
+feature, not a core value proposition.
+
+## Decision Framework
+
+When choosing between directions, rank on this matrix:
+
+|                | High Feasibility | Low Feasibility |
+| -------------- | ---------------- | --------------- |
+| **High Value** | Do this first    | Worth the risk  |
+| **Low Value**  | Only if trivial  | Don't do this   |
+
+Then use differentiation as the tiebreaker between options in the same quadrant.
+
+## MVP Scoping Principles
+
+When defining MVP scope for the chosen direction:
+
+1. **One job, done well.** The MVP should nail exactly one user job. Not three
+   jobs done partially.
+2. **The riskiest assumption first.** The MVP's primary purpose is to test the
+   assumption most likely to be wrong.
+3. **Time-box, not feature-list.** "What can we build and test in [timeframe]?"
+   is better than "What features do we need?"
+4. **The 'Not Doing' list is mandatory.** Explicitly name what you're cutting
+   and why. This prevents scope creep and forces honest prioritization.
+5. **If it's not embarrassing, you waited too long.** The first version should
+   feel incomplete to the builder. If it doesn't, you over-built.

package/.agents/skills/core/idea-refinement/scripts/idea-refine.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+set -e
+
+# This script helps initialize the ideas directory for the idea-refine skill.
+
+IDEAS_DIR="docs/ideas"
+
+if [ ! -d "$IDEAS_DIR" ]; then
+  mkdir -p "$IDEAS_DIR"
+  echo "Created directory: $IDEAS_DIR" >&2
+else
+  echo "Directory already exists: $IDEAS_DIR" >&2
+fi
+
+echo "{\"status\": \"ready\", \"directory\": \"$IDEAS_DIR\"}"

package/.agents/skills/core/incremental-implementation/SKILL.md

@@ -0,0 +1,271 @@
+---
+name: incremental-implementation
+description:
+  Delivers changes incrementally. Use when implementing any feature or change
+  that touches more than one file. Use when you're about to write a large amount
+  of code at once, or when a task feels too big to land in one step.
+---
+
+# Incremental Implementation
+
+## Policy Capsule
+
+- Deliver in thin vertical slices: **Implement → Test → Verify → Commit → Next slice**. Never write more than ~100 lines before testing.
+- Each slice MUST leave the system in a working, testable state — build green, existing tests pass, type-check and lint clean.
+- Each commit changes one logical thing; never mix refactors with features or formatting with behavior.
+- Apply Simplicity First: write the naive, obviously-correct version. Three similar lines beats a premature abstraction; do not build for hypothetical future requirements.
+- Enforce Scope Discipline: touch only what the task requires. No drive-by cleanups, import re-orderings, comment deletions, or syntax modernizations in files you're "just reading" — note them instead.
+- Gate incomplete work behind a feature flag rather than holding a long-lived branch; default new behaviour to safe / opt-in.
+- Keep increments rollback-friendly: prefer additive changes, ship DB migrations with rollbacks, and never delete + replace in the same commit.
+- Prefer vertical slices that deliver end-to-end functionality; use contract-first slicing only when backend/frontend must develop in parallel, and risk-first slicing when the riskiest piece dominates the plan.
+- Verify the increment checklist before moving on: tests pass, build succeeds, types check, lint clean, change committed with a descriptive message.
+
+## Overview
+
+Build in thin vertical slices — implement one piece, test it, verify it, then
+expand. Avoid implementing an entire feature in one pass. Each increment should
+leave the system in a working, testable state. This is the execution discipline
+that makes large features manageable.
+
+## When to Use
+
+- Implementing any multi-file change
+- Building a new feature from a task breakdown
+- Refactoring existing code
+- Any time you're tempted to write more than ~100 lines before testing
+
+**When NOT to use:** Single-file, single-function changes where the scope is
+already minimal.
+
+## The Increment Cycle
+
+```text
+┌──────────────────────────────────────┐
+│                                      │
+│   Implement ──→ Test ──→ Verify ──┐  │
+│       ▲                           │  │
+│       └───── Commit ◄─────────────┘  │
+│              │                       │
+│              ▼                       │
+│          Next slice                  │
+│                                      │
+└──────────────────────────────────────┘
+```
+
+For each slice:
+
+1. **Implement** the smallest complete piece of functionality
+2. **Test** — run the test suite (or write a test if none exists)
+3. **Verify** — confirm the slice works as expected (tests pass, build succeeds,
+   manual check)
+4. **Commit** -- save your progress with a descriptive message (see
+   `git-workflow-and-versioning` for atomic commit guidance)
+5. **Move to the next slice** — carry forward, don't restart
+
+## Slicing Strategies
+
+### Vertical Slices (Preferred)
+
+Build one complete path through the stack:
+
+```text
+Slice 1: Create a task (DB + API + basic UI)
+    → Tests pass, user can create a task via the UI
+
+Slice 2: List tasks (query + API + UI)
+    → Tests pass, user can see their tasks
+
+Slice 3: Edit a task (update + API + UI)
+    → Tests pass, user can modify tasks
+
+Slice 4: Delete a task (delete + API + UI + confirmation)
+    → Tests pass, full CRUD complete
+```
+
+Each slice delivers working end-to-end functionality.
+
+### Contract-First Slicing
+
+When backend and frontend need to develop in parallel:
+
+```text
+Slice 0: Define the API contract (types, interfaces, OpenAPI spec)
+Slice 1a: Implement backend against the contract + API tests
+Slice 1b: Implement frontend against mock data matching the contract
+Slice 2: Integrate and test end-to-end
+```
+
+### Risk-First Slicing
+
+Tackle the riskiest or most uncertain piece first:
+
+```text
+Slice 1: Prove the WebSocket connection works (highest risk)
+Slice 2: Build real-time task updates on the proven connection
+Slice 3: Add offline support and reconnection
+```
+
+If Slice 1 fails, you discover it before investing in Slices 2 and 3.
+
+## Implementation Rules
+
+### Rule 0: Simplicity First
+
+Before writing any code, ask: "What is the simplest thing that could work?"
+
+After writing code, review it against these checks:
+
+- Can this be done in fewer lines?
+- Are these abstractions earning their complexity?
+- Would a staff engineer look at this and say "why didn't you just..."?
+- Am I building for hypothetical future requirements, or the current task?
+
+```text
+SIMPLICITY CHECK:
+✗ Generic EventBus with middleware pipeline for one notification
+✓ Simple function call
+
+✗ Abstract factory pattern for two similar components
+✓ Two straightforward components with shared utilities
+
+✗ Config-driven form builder for three forms
+✓ Three form components
+```
+
+Three similar lines of code is better than a premature abstraction. Implement
+the naive, obviously-correct version first. Optimize only after correctness is
+proven with tests.
+
+### Rule 0.5: Scope Discipline
+
+Touch only what the task requires.
+
+Do NOT:
+
+- "Clean up" code adjacent to your change
+- Refactor imports in files you're not modifying
+- Remove comments you don't fully understand
+- Add features not in the spec because they "seem useful"
+- Modernize syntax in files you're only reading
+
+If you notice something worth improving outside your task scope, note it — don't
+fix it:
+
+```text
+NOTICED BUT NOT TOUCHING:
+- src/utils/format.ts has an unused import (unrelated to this task)
+- The auth middleware could use better error messages (separate task)
+→ Want me to create tasks for these?
+```
+
+### Rule 1: One Thing at a Time
+
+Each increment changes one logical thing. Don't mix concerns:
+
+**Bad:** One commit that adds a new component, refactors an existing one, and
+updates the build config.
+
+**Good:** Three separate commits — one for each change.
+
+### Rule 2: Keep It Compilable
+
+After each increment, the project must build and existing tests must pass. Don't
+leave the codebase in a broken state between slices.
+
+### Rule 3: Feature Flags for Incomplete Features
+
+If a feature isn't ready for users but you need to merge increments:
+
+```typescript
+// Feature flag for work-in-progress
+const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true';
+
+if (ENABLE_TASK_SHARING) {
+  // New sharing UI
+}
+```
+
+This lets you merge small increments to the main branch without exposing
+incomplete work.
+
+### Rule 4: Safe Defaults
+
+New code should default to safe, conservative behavior:
+
+```typescript
+// Safe: disabled by default, opt-in
+export function createTask(data: TaskInput, options?: { notify?: boolean }) {
+  const shouldNotify = options?.notify ?? false;
+  // ...
+}
+```
+
+### Rule 5: Rollback-Friendly
+
+Each increment should be independently revertable:
+
+- Additive changes (new files, new functions) are easy to revert
+- Modifications to existing code should be minimal and focused
+- Database migrations should have corresponding rollback migrations
+- Avoid deleting something in one commit and replacing it in the same commit —
+  separate them
+
+## Working with Agents
+
+When directing an agent to implement incrementally:
+
+```text
+"Let's implement Task 3 from the plan.
+
+Start with just the database schema change and the API endpoint.
+Don't touch the UI yet — we'll do that in the next increment.
+
+After implementing, run `npm test` and `npm run build` to verify
+nothing is broken."
+```
+
+Be explicit about what's in scope and what's NOT in scope for each increment.
+
+## Increment Checklist
+
+After each increment, verify:
+
+- [ ] The change does one thing and does it completely
+- [ ] All existing tests still pass (`npm test`)
+- [ ] The build succeeds (`npm run build`)
+- [ ] Type checking passes (`npx tsc --noEmit`)
+- [ ] Linting passes (`npm run lint`)
+- [ ] The new functionality works as expected
+- [ ] The change is committed with a descriptive message
+
+## Common Rationalizations
+
+| Rationalization                                    | Reality                                                                                           |
+| -------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
+| "I'll test it all at the end"                      | Bugs compound. A bug in Slice 1 makes Slices 2-5 wrong. Test each slice.                          |
+| "It's faster to do it all at once"                 | It _feels_ faster until something breaks and you can't find which of 500 changed lines caused it. |
+| "These changes are too small to commit separately" | Small commits are free. Large commits hide bugs and make rollbacks painful.                       |
+| "I'll add the feature flag later"                  | If the feature isn't complete, it shouldn't be user-visible. Add the flag now.                    |
+| "This refactor is small enough to include"         | Refactors mixed with features make both harder to review and debug. Separate them.                |
+
+## Red Flags
+
+- More than 100 lines of code written without running tests
+- Multiple unrelated changes in a single increment
+- "Let me just quickly add this too" scope expansion
+- Skipping the test/verify step to move faster
+- Build or tests broken between increments
+- Large uncommitted changes accumulating
+- Building abstractions before the third use case demands it
+- Touching files outside the task scope "while I'm here"
+- Creating new utility files for one-time operations
+
+## Verification
+
+After completing all increments for a task:
+
+- [ ] Each increment was individually tested and committed
+- [ ] The full test suite passes
+- [ ] The build is clean
+- [ ] The feature works end-to-end as specified
+- [ ] No uncommitted changes remain

package/.agents/skills/core/introducing-a-baseline-gate/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: introducing-a-baseline-gate
+description:
+  Land a new CI check that asserts on a body of pre-existing state
+  (doc-drift, lint-vocabulary, dependency-cycle, missing-test-coverage,
+  unused-export). Use when introducing a gate whose first run would
+  surface latent findings — the introducing Story MUST guarantee the
+  gate exits 0 at merge, not just that the cited discrepancies pass.
+---
+
+# Skill: Introducing a Baseline-Style Gate
+
+## Policy Capsule
+
+- A new check that asserts on pre-existing state MUST exit 0 at merge time. Wiring the gate into CI without proving it's green ships a red gate that blocks every downstream Story.
+- "The cited discrepancies are fixed" is **not** the AC. The AC is **"the gate exits 0 against the full repository on the merge commit"** — write it in the Story body in those words.
+- Choose one of two landing shapes before you write the AC: **advisory-first** (gate exits 0 with warnings; a follow-up Story flips it to blocking) or **populate-the-baseline** (the introducing Story fixes every existing finding in the same PR, or writes them to an ignore-list / baseline snapshot the gate respects).
+- Run the gate against `main` (or `epic/<id>`) **before** writing the AC. The findings count it surfaces is the scope of what landing-green will cost.
+- Wire the gate into `.agentrc.json` `github.branchProtection.requiredChecks` in the **same PR** that ships the gate's first green run — never split "add the check script" from "make it required".
+- Never land a gate red and rely on a follow-up Story to populate the baseline. The window between merge and the follow-up landing blocks every Story in flight.
+
+## When to reach for this
+
+Reach for this skill whenever you're introducing a check whose **first
+run on the existing codebase would surface findings you didn't author**.
+That includes (but is not limited to):
+
+- **Doc-drift gates** — `check-lifecycle-doc-drift.js`, "docs/X.md must
+  enumerate every Y in `src/Y/`", "README badge list must match the CI
+  workflow file list".
+- **Lint-vocabulary gates** — "no `TODO` without an issue link", "every
+  exported function must have a JSDoc summary", "every `agent::*` label
+  must appear in `label-constants.js`".
+- **Dependency-cycle / boundary gates** — "no import from `app/` into
+  `lib/`", "no cycle in module graph", "every workspace dep declared at
+  the right `package.json` level".
+- **Coverage-shape gates** — "every public API surface in
+  `tests/contract/**` has at least one negative-path test", "every
+  feature flag defined in `flags.ts` is referenced".
+- **Baseline-numeric gates** — Lighthouse / bundle-size / CRAP first
+  introduction. (For the numeric-ratchet shape specifically, also read
+  `stack/qa/lighthouse-baseline`.)
+
+If the check only fires on **new** code (e.g. a lint rule wired with
+`--cache` against the diff, or a hook scoped to staged files), this
+skill is not required — there's no latent-state landmine.
+
+## The Trap (Why This Skill Exists)
+
+**Epic #2880, Wave 1.** Story #2895 introduced
+`check-lifecycle-doc-drift.js` — a gate that asserts every entry in the
+project's lifecycle event registry has a matching row in
+`docs/LIFECYCLE.md`. The Story's AC required correcting 3 cited
+discrepancies and adding 2 new event rows. The gate landed wired into
+CI. The first CI run on the **next** Story (#2898) reported **11
+pre-existing drift findings** — drift that had been latent for months,
+silent because no gate enforced it.
+
+Stories #2898 and #2900 were both blocked. A hotfix commit on
+`epic/2880` (5e3ef962) had to populate the full listener table before
+wave 1 could merge. The cost was a half-day of wave-1 wall-clock and
+two interrupted Stories.
+
+**The diagnosis:** the introducing Story's AC was scoped to "fix what
+we cited", not "the gate is green". Those are different ACs. The
+second one is the load-bearing one.
+
+This skill exists so the next drift-style gate doesn't replay that
+pattern.
+
+## Two Landing Shapes — Pick One Before AC Authoring
+
+### Shape A: Advisory-First (exit 0 + warnings)
+
+Land the gate as **non-blocking** in the introducing Story. The script
+exits 0 even when findings exist, but prints them as warnings (and
+optionally posts them as a PR comment). A follow-up Story drives the
+findings count to zero, then flips the gate to blocking
+(`process.exit(1)` on finding-count > 0) and adds it to
+`requiredChecks`.
+
+**When to choose this shape:**
+
+- The existing-state findings are numerous (10+) and a one-shot fix
+  would balloon the introducing Story's scope.
+- The findings need per-finding owner triage (each row is a different
+  module's bug).
+- You want the warnings to surface in PRs immediately so contributors
+  can fix-as-they-touch.
+
+**Required AC line:**
+
+> "The gate runs in advisory mode (exits 0 with warnings on the full
+> repo). The follow-up Story #<NNN> flips it to blocking."
+
+The follow-up Story MUST exist as a real ticket on the board before the
+introducing Story closes — otherwise "follow-up" is a euphemism for
+"never".
+
+### Shape B: Populate-the-Baseline (exit 0 from day one)
+
+The introducing Story includes the work to drive existing findings to
+zero. Two sub-shapes:
+
+1. **Fix-them-all.** Edit the docs / add the missing tests / break the
+   cycles. The PR diff includes the gate code **and** the
+   findings-resolution diff. The first CI run is green.
+2. **Snapshot-as-baseline.** Write the current findings to a committed
+   ignore-list (`baselines/<gate>-ignore.json`) that the gate reads at
+   startup. The gate exits 0 when the only failures are in the ignore
+   list, and exits non-zero on any **new** finding. A follow-up Story
+   shrinks the ignore list to empty.
+
+**When to choose this shape:**
+
+- The findings count is small (≤ 10) and tractable in one PR.
+- Or: the findings reflect real bugs that should be fixed, not papered
+  over.
+- Or: an ignore-list snapshot is a meaningful artifact (it answers
+  "what's our drift debt right now?").
+
+**Required AC line:**
+
+> "On the merge commit, `<gate-script>` exits 0 against the full
+> repository. The gate is wired into `requiredChecks` in this PR."
+
+## Pre-Authoring Step: Run the Gate Against `main`
+
+**Before** writing the AC, run the gate script against `main` (or
+`epic/<id>`) locally and count the findings.
+
+```bash
+# In the introducing Story's worktree, with the gate script written:
+node .agents/scripts/<new-gate>.js
+echo "exit=$?"
+```
+
+That number — the **pre-existing finding count** — is the budget the
+Story is choosing to spend. Write it in the Story body:
+
+```text
+## Pre-existing finding count (as of <SHA>)
+- N findings on main / epic/<id>
+- Landing shape: <Advisory-First | Populate-the-Baseline:fix |
+  Populate-the-Baseline:snapshot>
+```
+
+If you skip this step you are gambling that the count is zero. It
+isn't, that's why you're adding the gate.
+
+## AC Checklist for a Drift-Style Gate Story
+
+Copy this checklist into the Story body. Every line MUST appear:
+
+- [ ] The gate script (`<path>`) exists and runs locally.
+- [ ] The pre-existing finding count on `<base-branch>` is documented
+      in the Story body.
+- [ ] The landing shape (Advisory-First / Populate-fix /
+      Populate-snapshot) is named in the Story body.
+- [ ] If Advisory-First: the follow-up Story (#<NNN>) exists on the
+      board with `type::story` and a link from this Story.
+- [ ] On the merge commit, the gate exits 0 against the full
+      repository (logs attached to the close comment).
+- [ ] The gate is wired into `.agentrc.json`
+      `github.branchProtection.requiredChecks` (Populate-shape) **or**
+      explicitly marked advisory (Advisory-First).
+- [ ] CI on the introducing PR shows the gate green.
+
+## Anti-patterns
+
+- **"The AC just says fix the cited cases."** The cited cases are the
+  spark that surfaced the need for the gate. The AC must cover the
+  whole forest, not just the tree the operator was standing under.
+- **"We'll wire it in now and clean up the drift in a follow-up."**
+  Every Story merged between "wire in" and "clean up" is blocked.
+  That's a wave-stopper, not a follow-up. Either populate-now or
+  advisory-now — never blocking-now-with-debt.
+- **"It's green locally, ship it."** Local environments routinely have
+  uncommitted state that the gate accepts. Verify against the **base
+  branch tip**, not `git status`-clean working tree.
+- **"The hotfix commit on the integration branch counts as cleanup."**
+  It counts as a Story-2895-class debt: the gate is green on
+  `epic/<id>` only because someone manually populated the gap.
+  Codify the populate work as scope of the introducing Story instead.
+- **No follow-up Story for Advisory-First.** "Advisory forever" means
+  the gate is decoration. Either commit to flipping it or don't ship
+  the advisory version.
+
+## Cross-references
+
+- **`stack/qa/lighthouse-baseline`** — for the **numeric-ratchet**
+  flavour of baseline gate (a number with a tolerance band that
+  ratchets only with intent). That skill's `--self-test` and
+  weekly-cadence patterns complement this one's landing-shape
+  patterns; the two skills cover orthogonal concerns (number-shape
+  vs. land-green).
+- **`core/baseline-refresh`** — once the gate exists and is blocking,
+  this skill governs how an intentional drift in the baseline is
+  refreshed without bypassing the gate.
+- **`core/ci-cd-and-automation`** — generic CI-pipeline conventions
+  (gate ordering, no-skip rule, branch-protection wiring) that this
+  skill specialises for the latent-state case.
+- **`.agents/rules/git-conventions.md` § Contract Cutovers** — a
+  drift-style gate is itself a contract cutover (the contract is "the
+  artifact and the source agree"). The hard-cutover policy applies:
+  land green in one PR, don't ship two-shape tolerance.
+- **Source incident:** Epic #2880 friction note **F-W1-1**
+  (LIFECYCLE.md drift exposure), hotfix
+  [`5e3ef962`](https://github.com/dsj1984/mandrel/commit/5e3ef962),
+  Stories
+  [#2895](https://github.com/dsj1984/mandrel/issues/2895),
+  [#2898](https://github.com/dsj1984/mandrel/issues/2898),
+  [#2900](https://github.com/dsj1984/mandrel/issues/2900).