BarkBowl Redesign Research Report

Full report

On this page

Executive summary

BarkBowl already has a strong premise, but the live public implementation currently undermines it. The homepage says BarkBowl is “premium dogfood for teams that eat their own roadmap,” prices work in engineering time, and invites users to browse Products, Time Cart, How It Works, Dogfooding Program, Field Reports, and About. In practice, the critical navigation paths for Time Cart, How It Works, Dogfooding Program, Field Reports, About, and Privacy return 404s, the products archive is empty, and the homepage exposes a raw [barkbowl_time_budget_calculator] shortcode instead of a functioning interactive tool. That combination makes the site feel unfinished, reduces trust, and prevents the joke from turning into an educational experience.

The right redesign direction is not “make it more like a normal ecommerce site.” The strongest BarkBowl source material defines it as a time-commerce dogfooding product whose central mechanic is that software teams “pay” with time rather than money, and whose honest architecture is a custom WordPress plugin with a branded theme rather than WooCommerce painted over. That premise is reinforced by WordPress guidance that site-critical functionality should live in plugins, not themes, and that custom post types should be registered in plugins so content remains portable if the theme changes.

The redesign should therefore do three things at once. First, restore credibility by fixing route integrity, page titles, seeded content, and core interactions. Second, make the site much funnier by leaning into “deadpan premium pet-retail seriousness applied to software waste.” Third, make it much more educational by pairing every joke with a plain-English translation, a visible time formula, a lesson link, and a practical async or process substitute. That “learn while you laugh” pattern is consistent with strong edutainment examples: Kahoot markets “interactive learning,” “real-time engagement,” and instant feedback, while Brilliant emphasizes visual, interactive, step-by-step learning and explicit progression through challenge, streaks, levels, and daily goals.

Technically, the most robust implementation is a strict WordPress split: a BarkBowl Theme for presentation and a BarkBowl Core plugin for custom content models, cart/session logic, REST controllers, telemetry, seeders, quiz scoring, simulator formulas, admin tools, and rollout controls. WordPress REST guidance supports versioned namespaces, route registration on rest_api_init, explicit permission_callback usage, controller classes, and JSON Schema-backed validation. For accessibility, target WCAG 2.2 AA for titles, labels, focus, keyboard access, and predictable navigation, then also support reduced motion as an additional design guardrail. For performance, build toward 75th percentile Core Web Vitals targets of LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1, and capture your own real-user monitoring rather than relying only on aggregate public data.

One limitation remains: this audit is based on the crawl-visible public site and the provided project documents. That is enough for a high-confidence redesign brief, but it is not the same thing as a full instrumented accessibility, JavaScript-behavior, or admin workflow audit. In particular, exact contrast values, full focus order, and current plugin/theme internals still require hands-on QA in the implementation environment.

Prioritized implementation checklist

The current highest-confidence priorities are below. The ordering reflects the live site’s broken trust path first, then core BarkBowl mechanics, then educational expansion, then optimization and launch governance. The rationale for that order comes directly from the present site failures, the WordPress architecture guidance, and the uploaded BarkBowl architecture documents.

Experience strategy and site architecture

BarkBowl should be positioned as a premium grocery parody for software teams, where the shelf joke is immediate but the lesson is equally immediate. The current site already signals the right conceptual raw material: products are categories like Feature Kibble, Bug Biscuits, Sprint Chow, Refactor Jerky, Incident Snacks, and Roadmap Rations; time, not money, is the currency; and “Build a Bowl” is the core action. The failure is not premise but follow-through. The redesign should preserve those aisles and the dogfooding/time-commerce fiction, then add a second layer that explicitly teaches how time burn accumulates in software delivery.

The top-line goals should be:

The required pages and routes should be these:

flowchart TD
    A[Home] --> B[Build a Bowl]
    A --> C[Learn]
    A --> D[Quiz Lab]
    A --> E[Field Reports]
    A --> F[Dogfooding Program]
    B --> G[Products]
    G --> H[Category Archive]
    H --> I[Product Detail]
    I --> J[Time Cart]
    I --> K[Related Lesson]
    K --> D
    D --> L[Quiz Result]
    L --> K
    E --> M[Field Report Detail]
    J --> N[Checkout Receipt]
    A --> O[Glossary]
    A --> P[About]

The architecture split should be strict because WordPress explicitly advises keeping design in themes and reusable, site-critical behavior in plugins; it also recommends putting custom post types in plugins so content remains portable if the theme changes.

flowchart LR
    A[BarkBowl Theme] --> B[Templates and Tokens]
    C[BarkBowl Core Plugin] --> D[CPTs and Taxonomies]
    C --> E[REST Controllers]
    C --> F[Cart and Receipt Engine]
    C --> G[Quiz and Simulator Engine]
    C --> H[Telemetry and Flags]
    E --> I[Browser TypeScript Modules]
    F --> J[Session Cookie]
    H --> K[Admin Dashboard]
    D --> L[WordPress Content Database]
    F --> M[Custom Runtime Tables]
    H --> M
    G --> M

The content model should be the following:

The visual system should reinforce “luxury dogfood packaging meets delivery telemetry dashboard” without becoming visually noisy. WCAG 2.2 AA requires descriptive titles and labels, visible focus, keyboard-operable interactions, and predictable information architecture, so the design system must privilege clarity first and humor second on critical paths.

Content system and seeded data

The seeded content should treat the catalog as the narrative shell and the educational layer as the real value. Current BarkBowl language already establishes the aisles; the new system should make each product card teach one operational lesson and guide users toward a short learning object. That is how the site becomes both much funnier and much more educational.

Seeded product catalog

Launch lessons

Field reports

Quiz Lab questions and results

Glossary

Time Cart, formulas, and simulator

Time currency should remain simple and legible. The prescription below follows the present site’s premise and the BarkBowl source material: keep the shelf label easy, expand the formula on detail pages, and make the receipt feel uncomfortably concrete.

The Time Burn Simulator should be a real interactive tool, not a shortcode placeholder. Its behavior should borrow from successful interactive-learning systems: clear inputs, immediate feedback, explanatory output, and a recommended next action.

Voice, tone, and sample copy

The voice should be deadpan, premium, observant, and systems-focused. The humor should punch at process waste, not at people. That fits the current BarkBowl premise and also protects usability: the more critical the task, the lower the joke density should be.

Engineering specification and launch governance

The engineering build should follow WordPress and web-platform guidance closely. Register custom REST routes on rest_api_init, use explicit namespaced and versioned routes, supply permission_callback for every route, use JSON Schema-backed validation and sanitization, and keep unknown payload properties out of write handlers. Use a narrow-scope host-only session cookie with Secure, HttpOnly, SameSite=Lax, and Path=/; store carts server-side in custom tables; and use transients only for caches because WordPress explicitly notes transient expiration is a maximum time, not a minimum. For telemetry, structure events so the system emits traces, metrics, and logs or log-equivalent analytics signals; for performance, instrument real-user monitoring in addition to lab checks.

Frontend architecture

Session and persistence model

REST routes

Because WordPress explicitly uses routes, endpoints, route namespaces, and controller classes in its REST model, the implementation should use namespaced controller classes rather than anonymous endpoint callbacks scattered across the plugin.

Sample JSON payloads

The REST layer should use stable schemas and reject unknown fields where appropriate. WordPress’s REST API schema guidance recommends JSON Schema-backed validation, including explicit properties, required fields, and the ability to reject additional properties.

Product payload

{
  "id": 101,
  "slug": "tiny-ticket-tender-bits",
  "title": "Tiny Ticket Tender Bits",
  "sku": "BB-FTR-TTB-009",
  "category": "feature-kibble",
  "tagline": "“Just one button” in bite-sized denial.",
  "translation": "Small requests expand once acceptance criteria appear.",
  "formula": "1h discovery + 5h build + 2h QA + 1h review",
  "typical_time_price_minutes": 540,
  "typical_time_price_label": "9 p-h",
  "what_it_teaches": "Tiny features are rarely tiny",
  "ingredients": [
    "single-sentence request",
    "hidden acceptance criteria",
    "one reviewer"
  ],
  "warning": "Expands on contact with stakeholders.",
  "async_substitute": "Clarifying Note Cup",
  "related_lesson_slug": "tiny-features-grow-teeth"
}

Cart add request

{
  "product_id": 101,
  "quantity": 1,
  "context": {
    "team_size": 6,
    "sprint_days": 10,
    "work_hours_per_day": 8
  }
}

Checkout receipt response

{
  "receipt_id": "bb_rcpt_20260611_8GQ2ZX",
  "created_at_utc": "2026-06-11T16:48:22Z",
  "session_id": "bb_sess_a8d3f4c29f",
  "items": [
    {
      "product_id": 101,
      "sku": "BB-FTR-TTB-009",
      "title": "Tiny Ticket Tender Bits",
      "quantity": 1,
      "subtotal_minutes": 540,
      "subtotal_label": "9 p-h"
    }
  ],
  "totals": {
    "minutes": 540,
    "person_hours": 9,
    "person_days": 1.125,
    "sprint_share_percent": 1.88,
    "burn_band": "snack"
  },
  "primary_lesson_slug": "tiny-features-grow-teeth",
  "disclaimer": "No money accepted. This receipt records time burn, not payment."
}

Telemetry event

{
  "event_name": "bb_cart_item_added",
  "event_version": 1,
  "occurred_at_utc": "2026-06-11T16:49:01Z",
  "session_id": "bb_sess_a8d3f4c29f",
  "route_name": "product_detail",
  "content_type": "product",
  "content_id": 101,
  "sku": "BB-FTR-TTB-009",
  "value_minutes": 540,
  "ui_surface": "pdp_primary_cta",
  "success": true,
  "flag_state": {
    "new_cart_drawer": true,
    "quiz_inline_recommendations": false
  }
}

Telemetry schema and KPIs

Accessibility checklist and ARIA patterns

WCAG 2.2 guidance requires meaningful page titles, visible focus, labels or instructions for inputs, keyboard operability, and predictable navigation. The WAI APG patterns further define how disclosures, tooltips, and modal dialogs should behave.

Tooltip pattern

<button
  type="button"
  aria-describedby="tip-time-price"
>
  What is this price?
</button>
<div id="tip-time-price" role="tooltip" hidden>
  BarkBowl prices snacks in team time, not money.
</div>

Disclosure pattern

<button
  type="button"
  aria-expanded="false"
  aria-controls="formula-panel-101"
>
  Show formula
</button>
<div id="formula-panel-101" hidden>
  1h discovery + 5h build + 2h QA + 1h review
</div>

Dialog pattern

<div
  role="dialog"
  aria-modal="true"
  aria-labelledby="cart-title"
  aria-describedby="cart-summary"
  hidden
>
  <h2 id="cart-title">Time Cart</h2>
  <p id="cart-summary">Review your selected snacks and total burn.</p>
  <button type="button">Close</button>
</div>

SEO and performance

Google’s Search guidance emphasizes useful, compelling content, descriptive title links, a clear main heading, sitemap submission, canonical URLs in sitemaps, and structured data that matches visible on-page content. BarkBowl’s current placeholder titles and broken routes are therefore both discoverability and trust problems.

Recommended schema is conservative: WebSite, Organization, BreadcrumbList, and where appropriate Article for field reports and lessons, only when the structured data reflects visible content. Use JSON-LD because Google recommends it when the setup allows it.

QA, launch checklist, and acceptance criteria

Paste-ready master prompt

The prompt below is designed to be handed directly to a multidisciplinary engineering, design, and content agent. It is intentionally implementation-forward and assumes no special hosting or analytics constraints beyond “modern supported WordPress environment.” It is derived from the current public site audit, the BarkBowl architecture documents, WordPress developer guidance, WCAG 2.2/WAI APG guidance, Google Search documentation, and current interactive-learning product patterns.

You are the implementation lead for a full coordinated redesign of BarkBowl, a WordPress-based satirical time-commerce product for software teams. Your job is to implement the redesign in one sweep across engineering, design, UX writing, content architecture, seeded data, analytics, accessibility, and launch QA.

Do not ask clarifying questions unless something is genuinely impossible. Make reasonable assumptions. Preserve the core BarkBowl premise: this is NOT a real store and NOT a conventional ecommerce site. It is a fake premium dogfood brand for software-team waste. The currency is time, not money. The site must become much funnier, much more educational, and much more trustworthy than the current public implementation.

NON-NEGOTIABLE POSITIONING

BarkBowl is:
- a premium grocery parody for software teams
- a time-commerce product where features, bugs, meetings, refactors, incidents, and roadmap rituals are priced in person-hours/person-days/sprint share
- educational: every joke must have an immediate plain-English translation and a practical lesson
- internally dogfooded: the BarkBowl cart, quiz, simulator, and telemetry must be treated as product features worth measuring

BarkBowl is NOT:
- a WooCommerce repaint
- a real payments funnel
- a pet nutrition education site
- a “clever brochure” with fake buttons and dead ends

CURRENT PROBLEMS TO FIX IN THIS SWEEP

Fix all of these as core acceptance criteria:
- critical navigation routes currently 404
- browser titles are weak/generic
- products archive is empty
- homepage exposes raw shortcode-like scaffolding
- the joke currently outruns explanation
- the site is not educational enough
- the cart premise is under-implemented
- the current public experience feels like a prototype, not a product

ARCHITECTURE DECISION

Build this with:
- one custom WordPress theme: barkbowl-theme
- one custom WordPress plugin: barkbowl-core

Do NOT build on WooCommerce.

Theme responsibilities:
- theme.json
- design tokens
- templates and template parts
- block patterns
- nav/footer/search/404
- page layout and editorial styling
- print styling for receipt pages
- non-critical presentational JS only

Plugin responsibilities:
- CPTs, taxonomies, and custom fields
- content seeders
- REST API controllers
- session management
- Time Cart logic
- checkout receipt creation
- quiz engine and result scoring
- Time Burn Simulator formulas
- telemetry endpoint and event schema
- feature flags / rollout ring support
- admin settings and dashboard

CUSTOM CONTENT MODEL

Create these custom post types:
- bb_product
- bb_lesson
- bb_field_report
- bb_quiz
- bb_glossary_term

Create these taxonomies:
- bb_product_category
- bb_work_stage
- bb_risk_level
- bb_team_appetite
- bb_teach_topic

Key bb_product fields:
- title
- slug
- sku
- tagline
- translation
- formula_display
- typical_time_price_minutes
- typical_time_price_label
- what_it_teaches
- ingredients[]
- warning
- async_substitute
- related_lesson_slug
- display_order
- hero_image_id

Key bb_lesson fields:
- title
- slug
- teaser
- summary
- learning_objective
- read_time_minutes
- sections[]
- checklist[]
- formula_callout
- related_products[]
- related_reports[]
- next_lesson_slug

Key bb_field_report fields:
- title
- slug
- summary
- situation
- what_happened
- what_it_taught
- related_lesson_slug
- related_products[]
- pull_quote

Key bb_quiz fields:
- title
- slug
- intro
- questions_json
- scoring_json
- result_archetypes_json
- completion_cta

Key bb_glossary_term fields:
- term
- slug
- short_definition
- long_definition
- plain_english_note
- related_terms[]
- related_lessons[]

Create custom runtime tables for:
- sessions
- cart items
- receipts
- telemetry events
- quiz attempts
- feature-flag assignments or overrides if needed

ROUTES TO BUILD

Top-level routes:
- /
- /build-a-bowl/
- /products/
- /product-category/{term}/
- /snack/{slug}/
- /time-cart/
- /how-it-works/
- /learn/
- /lesson/{slug}/
- /quiz-lab/
- /quiz-lab/team-overfeeding-checkup/
- /field-reports/
- /field-report/{slug}/
- /dogfooding-program/
- /glossary/
- /about/
- /privacy/
- /accessibility/
- /search/
- /404/

NAVIGATION MODEL

Primary nav:
- Build a Bowl
- Learn
- Quiz Lab
- Time Cart
- Field Reports
- Dogfooding Program
- About

Footer nav:
- Privacy
- Accessibility
- Glossary
- Search
- Sitemap

VOICE AND TONE RULES

Voice:
- deadpan
- premium retail serious
- observant
- systems-focused
- never smug
- never mean to individuals
- jokes target process waste, ambiguity, ritual inflation, delivery theater, approval sprawl, and meeting gravity

Humor density:
- hero and banners: 7/10
- product cards: 6/10
- product detail pages: 5/10
- lessons and glossary: 3/10
- quiz results: 5/10
- receipts: 4/10
- errors/forms/accessibility/legal text: 1/10

Core writing pattern:
1. joke line
2. plain-English translation
3. time formula
4. lesson link
5. async substitute

VISUAL SYSTEM

Create a design system with this feel:
- premium dogfood packaging + delivery dashboard
- warm cream background, dark ink text, brass/golden aisle accents, strong category-coded support colors
- display serif + neutral sans body + monospace for formulas/receipts
- rounded cards, shelf labels, barcode-style details, “no money accepted” stamp treatment
- subtle motion only
- reduced-motion support must disable non-essential motion

Use these breakpoints:
- xs 0–599
- sm 600–899
- md 900–1199
- lg 1200–1439
- xl 1440+

ASSET LIST TO PRODUCE

- primary wordmark logo
- compact icon/logo
- 6 aisle icons
- 24 product illustrations
- 8 lesson icons
- 6 field report thumbnails
- 6 quiz result badges
- receipt stamps
- social OG images
- simulator diagram

TIME CURRENCY AND FORMULAS

The site’s unit system must be:
- min
- hr
- p-h
- p-day
- sprint-share %

Formulas:
- person_hours = minutes / 60
- person_days = person_hours / 8
- sprint_share_percent = person_hours / (team_size * sprint_days * work_hours_per_day) * 100
- cart_subtotal_minutes = sum(item_minutes * quantity)
- async_savings = sync_total_person_hours - async_total_person_hours

Burn bands:
- under 5% sprint = snack
- 5–15% = meal
- 15–30% = crate
- above 30% = kennel fire

SESSION AND CART RULES

Use a host-only session cookie:
- __Host-barkbowl_session
- Secure
- HttpOnly
- SameSite=Lax
- Path=/

Store cart state server-side.
Cart TTL: 72 hours after first add.
Show countdown only on cart and receipt-adjacent surfaces, not everywhere.
Do not use transients as the source of truth for cart authority.
Use transients only for cacheable catalog/bootstrap data.

REST API

Implement versioned routes under /wp-json/barkbowl/v1/

Required endpoints:
- GET /bootstrap
- GET /products
- GET /products/{id}
- GET /lessons
- GET /lessons/{slug}
- GET /cart
- POST /cart/items
- PATCH /cart/items/{key}
- DELETE /cart/items/{key}
- POST /checkout
- POST /quiz/{slug}/score
- POST /telemetry
- GET /admin/dashboard

Implementation rules:
- register routes on rest_api_init
- every route has explicit permission_callback
- use controller classes
- validate and sanitize request bodies with schema-backed rules
- reject unknown write properties where practical
- use UTC for operational timestamps

FRONTEND TYPESCRIPT MODULES

Create a clean TS module structure:
- core/http.ts
- core/session.ts
- core/events.ts
- catalog/filters.ts
- catalog/cards.ts
- product/formula.ts
- cart/store.ts
- cart/drawer.ts
- receipt/view.ts
- lesson/progress.ts
- quiz/engine.ts
- simulator/formulas.ts
- telemetry/client.ts
- a11y/disclosure.ts
- a11y/tooltip.ts
- a11y/dialog.ts

Use predictable state boundaries. Do not smear business logic into templates.

SEEDED PRODUCT CATALOG

Seed exactly these 24 products:

Feature Kibble
1. Tiny Ticket Tender Bits | BB-FTR-TTB-009 | “Just one button” in bite-sized denial. | Small requests expand once acceptance criteria appear. | 1h discovery + 5h build + 2h QA + 1h review | 9 p-h | teaches tiny features are rarely tiny | ingredients: single-sentence request, hidden acceptance criteria, one reviewer | warning: expands on contact with stakeholders | async substitute: Clarifying Note Cup
2. OAuth Kibble Pro | BB-FTR-OAU-025 | Single sign-on, multiple sign-offs. | Enterprise auth has hidden integration and rollout cost. | 2h discovery + 16h build + 4h QA + 2h review + 1h rollout | 25 p-h | teaches integration work hides in platform asks | ingredients: enterprise ask, security crumbs, integration hair | warning: may require new env variables | async substitute: Decision memo + integration spike
3. Dashboard Variety Box | BB-FTR-DAS-044 | Packed with metrics nobody wanted until the exec invite landed. | Dashboards cost scoping, data, QA, and polish. | 3h scoping + 24h build + 8h data wrangling + 6h QA + 3h polish | 44 p-h | teaches metrics should justify maintenance cost | ingredients: exec curiosity, orphan metrics, CSV dust | warning: frequently mistaken for strategy | async substitute: Weekly KPI digest
4. Edge-Case Feast | BB-FTR-ECF-021 | Happy path sold separately. | Exceptions multiply implementation effort. | 2h scoping + 8h build + 6h exceptions + 3h QA + 2h review | 21 p-h | teaches edge cases are where estimates go to molt | ingredients: optional cases, legal sprinkles, boolean crumbs | warning: case count triples after demo | async substitute: Rule table first

Bug Biscuits
5. Flake Nibbles | BB-BUG-FLK-003 | Now with intermittent crunch. | Flaky bugs consume time even before a fix exists. | 30m triage + 1h repro + 1h fix + 30m verify | 3 p-h | teaches reproduction quality matters | ingredients: race-condition flakes, stale mocks, timing dust | warning: usually disappears during screen share | async substitute: Repro template
6. Regression Rounds | BB-BUG-REG-006 | Baked from yesterday’s confidence. | Regressions cost more than the original defect. | 1h triage + 2h fix + 2h QA + 1h release watch | 6 p-h | teaches every fix needs guardrails | ingredients: previous fix residue, test gap crumbs, release steam | warning: returns after cheerful deploy notes | async substitute: Guardrail test first
7. Cannot-Repro Chews | BB-BUG-CNR-003 | Mystery flavor, browser-dependent. | Weak bug reports turn diagnosis into archaeology. | 45m intake + 1h logs + 1h retry + 30m follow-up | 3.25 p-h | teaches better intake reduces wasted cycles | ingredients: vague screenshots, browser variance, mystery gravy | warning: diagnosis may exceed symptom size | async substitute: Structured bug intake
8. Hotfix Sprinkles | BB-BUG-HFX-005 | Add directly to Friday. | Hotfixes compress decision-making and raise risk. | 30m triage + 2h fix + 1h review + 1.5h deploy/check | 5 p-h | teaches urgency taxes code quality | ingredients: alert pings, narrowed scope, Friday fumes | warning: consume before weekend | async substitute: Feature flag rollback

Sprint Chow
9. Commitment Chow Family Pack | BB-SPR-CMT-006 | Over-portioned promises for growing roadmaps. | Sprint plans fail when commitments outrun capacity. | 2h scope pack + 1h dependency check + 2h tradeoff debate + 1h plan rewrite | 6 p-h | teaches commitments need capacity math | ingredients: promises, dependency glitter, slide garnish | warning: best before priorities change | async substitute: Single-page sprint brief
10. Estimation Nuggets | BB-SPR-EST-010 | Now with objective-looking numbers. | Estimation creates confidence, not certainty. | 90m refinement × 6 + 30m re-baseline | 9.5 p-h | teaches precision is not predictability | ingredients: cards, poker faces, optimism powder | warning: creates false certainty when overfed | async substitute: Written sizing notes
11. Ceremony Sampler Sack | BB-SPR-CER-049 | A balanced blend of planning, updates, reviewing, and regretting. | Scrum ceremonies can multiply cost when they stop serving delivery. | 2h planning × 7 + 15m daily × 7 × 10 + 1.5h review × 7 + 1h retro × 7 | 49 p-h | teaches meetings are parallel burn | ingredients: planning oats, daily crumbs, review glaze, retro salt | warning: not a substitute for delivery | async substitute: Async status board
12. Hardening Week Kibble | BB-SPR-HAR-138 | Crunchy release prep for teams that treat QA like weather. | Late quality work becomes a sprint-consuming event. | (5 days × 3 engineers × 8h) + (2 days × 1 QA × 8h) + 2h freeze huddle | 138 p-h | teaches quality must move left | ingredients: late defects, release anxiety, freeze crystals | warning: usually means quality arrived late | async substitute: Definition-of-Done tune-up

Refactor Jerky
13. Naming Cleanup Strips | BB-REF-NAM-004 | Lean, chewy, and invisible to stakeholders. | Small clarity refactors reduce future friction. | 1h scan + 2h rename + 1h tests | 4 p-h | teaches shared language speeds teams up | ingredients: vague classes, inconsistent nouns, grep smoke | warning: may trigger unrelated opinions | async substitute: Naming glossary
14. Dependency Detox Twists | BB-REF-DDT-014 | Removes stale packages and reveals hidden trauma. | Dependency maintenance is real product work. | 2h audit + 6h upgrade + 4h fallout + 2h QA | 14 p-h | teaches forgotten dependencies compound risk | ingredients: stale packages, CVE dust, API drift | warning: can summon a changelog storm | async substitute: Dependency audit cadence
15. Test Harness Jerky | BB-REF-THJ-010 | Dense with future relief. | Building better tests buys down future bug cost. | 2h harness + 6h tests + 2h stabilize | 10 p-h | teaches automation is an anti-regression asset | ingredients: manual steps, copy-paste residue, assertion crumbs | warning: feels slow until next outage | async substitute: Golden-path smoke tests
16. Architectural Reseal Pack | BB-REF-ARP-028 | No visible features. Strong future chew. | Deep refactors are option purchases for future speed. | 4h design + 16h refactor + 8h regression | 28 p-h | teaches hidden architecture still shapes throughput | ingredients: coupling, duplicate logic, hidden seams | warning: stakeholders may see no visible change | async substitute: Architectural decision record

Incident Snacks
17. Pager Crunchies | BB-INC-PGR-003 | Best served loud. | Even small incidents destroy planned focus. | (15m ack × 3) + (45m diagnose × 2) + (30m comms × 2) | 3.25 p-h | teaches interruptions have real operating cost | ingredients: alerts, adrenaline, half context | warning: pairs poorly with sleep | async substitute: Runbook refresh
18. Severity-One Stew | BB-INC-SEV-015 | A whole-meal derailment. | Major incidents consume multiple people and displace roadmap work. | (2h incident cell × 4) + (2h recovery × 3) + 1h stakeholder brief | 15 p-h | teaches incidents tax planned delivery | ingredients: incident channel foam, rollback stock, customer comms | warning: consumes the whole sprint | async substitute: Tabletop drill
19. Rollback Bisque | BB-INC-RBK-004 | Rich, reversible, occasionally lumpy. | Rollbacks are cheaper when designed early. | 30m decision + 1h rollback + 2h verify | 3.5 p-h | teaches safe release design reduces blast radius | ingredients: release notes, restore scripts, humility | warning: not all rollbacks are clean | async substitute: Canary release
20. Postmortem Pumpkin Bites | BB-INC-PMB-004 | Gentle on blame, firm on learning. | Retrospective rigor matters after incidents. | 1h timeline + 1h write-up + 1h review + 1h action follow-up | 4 p-h | teaches learnings need owners and follow-through | ingredients: timeline puree, action-item seeds, memory fog | warning: spoils if blame is added | async substitute: Blameless write-up template

Roadmap Rations
21. Stakeholder Alignment Feast | BB-RDM-ALN-015 | Slow-cooked consensus in a premium tray. | Broad approval chains inflate time cost. | 60m × 12 attendees × 1.25 repetition factor | 15 p-h | teaches approval sprawl is measurable | ingredients: opinions, calendars, alignment broth | warning: frequently repeats itself | async substitute: Recorded walkthrough + comment window
22. Reprioritization Pellets | BB-RDM-RPR-008 | Same backlog, different weather. | Constant priority changes destroy flow efficiency. | 45m prep + 1h realignment × 6 + 1h board rewrite | 7.75 p-h | teaches churn has carrying cost | ingredients: new-ask glaze, stale commitments, roadmap binder | warning: destroys momentum in large doses | async substitute: Weekly intake cutoff
23. Committee Product Ownership Platter | BB-RDM-CPO-006 | Five approvers, one backlog, zero final answer. | Product ownership by committee slows decisions. | (30m × 5 approvers) + 2h reconciliation + 1h roadmap polish | 5.5 p-h | teaches single-threaded ownership matters | ingredients: five approvers, one backlog, garnish of hesitancy | warning: never fully sold out | async substitute: Single-threaded owner
24. Q4 Promise Loaf | BB-RDM-Q4P-007 | Sliced thin for maximum confidence. | Roadmaps are inventory, not output. | 2h planning + 2h roadmap art + 2h dependency guesswork + 1h exec polish | 7 p-h | teaches announced work is not delivered work | ingredients: quarterly confidence, dependency glaze, optimism crust | warning: shelf life ends at implementation | async substitute: Capacity-first planning

LAUNCH LESSONS

Seed these 8 lessons:
- time-is-the-price
- tiny-features-grow-teeth
- meetings-are-parallel-burn
- bugs-charge-interest
- refactors-buy-future-speed
- incidents-steal-planned-work
- roadmaps-are-inventory-not-output
- dogfooding-rings-and-release-safety

Each lesson must include:
- joke line
- plain summary
- one formula or worked example
- one checklist
- related products
- related field report
- next lesson CTA

FIELD REPORTS

Seed these 6 field reports:
- we-added-one-tiny-feature-and-lost-a-tuesday
- the-cart-expired-during-refinement-as-designed
- why-story-points-taste-like-chicken
- we-bought-an-incident-and-shipped-a-postmortem
- the-roadmap-was-full-and-the-sprint-was-hungry
- how-a-refactor-paid-back-in-three-releases

QUIZ LAB

Create flagship quiz:
- slug: team-overfeeding-checkup
- title: What Is Your Team Overfeeding?
- 8 questions focused on scope creep, approval count, meeting bias, bug quality, refactor maturity, incident interruption, roadmap churn, and async readiness
- return one of 6 result archetypes:
  - Feature Kibble Pack
  - Bug Biscuit Kennel
  - Sprint Chow Club
  - Refactor Jerky Syndicate
  - Incident Snack Response Unit
  - Roadmap Rations Cooperative

Every result page must include:
- diagnosis headline
- short explanation
- two recommended products
- one linked lesson
- one linked field report
- one async substitute recommendation

GLOSSARY

Seed these terms:
- dogfooding
- time commerce
- person-hour
- person-day
- sprint share
- TTL
- async substitute
- scope creep
- context-switch tax
- review drag
- definition of done
- ring rollout
- blameless postmortem
- WIP
- lead time

TIME BURN SIMULATOR

Build a real simulator with inputs:
- team size
- sprint length in days
- work hours per day
- meetings per week
- average attendees
- interruptions per person per day
- review hops per item
- scope changes per sprint
- incident count per sprint
- async replacement rate

Outputs:
- person-hours burned
- person-days
- sprint-share %
- largest burn source
- async savings opportunity
- burn band
- recommended product
- recommended lesson
- recommended field report

TELEMETRY

Emit at least these events:
- bb_page_view
- bb_product_card_viewed
- bb_product_detail_viewed
- bb_formula_expanded
- bb_async_substitute_clicked
- bb_cart_item_added
- bb_cart_item_removed
- bb_cart_viewed
- bb_cart_expired
- bb_checkout_started
- bb_receipt_created
- bb_quiz_started
- bb_quiz_completed
- bb_lesson_started
- bb_lesson_completed
- bb_field_report_opened
- bb_simulator_run
- bb_simulator_apply_recommendation
- bb_frontend_error
- bb_api_error

Telemetry schema fields:
- event_name
- event_version
- occurred_at_utc
- session_id
- route_name
- content_type
- content_id or slug
- ui_surface
- value_minutes
- duration_ms
- success
- error_code
- flag_state
- device_class

KPIs:
- learning engagement rate
- build-a-bowl completion rate
- quiz completion rate
- lesson completion rate
- async substitute click rate
- cart TTL expiry rate
- route error rate
- 75th percentile route-level CWV
- dogfooding ring adoption
- receipt-to-return rate

ACCESSIBILITY REQUIREMENTS

Target WCAG 2.2 AA.
Must support:
- descriptive page titles
- visible focus indicators
- keyboard access for all critical interactions
- visible labels and instructions
- skip link on all templates
- non-color-only errors
- disclosure aria-expanded/aria-controls
- tooltip aria-describedby/role=tooltip
- dialog role=dialog aria-modal=true return focus to trigger
- reduced-motion support for non-essential animation
- sensible screen-reader order on cards, cart, quiz, receipt

SEO REQUIREMENTS

Implement:
- descriptive unique titles
- aligned visible H1s
- useful meta descriptions
- crawlable internal links
- sitemap.xml
- robots.txt sitemap reference
- canonicals
- OG/Twitter metadata
- JSON-LD only for visible content
- Organization, WebSite, BreadcrumbList, Article where appropriate

PERFORMANCE REQUIREMENTS

Build toward:
- LCP <= 2.5s at 75th percentile
- INP <= 200ms at 75th percentile
- CLS <= 0.1 at 75th percentile
- first-load JS <= 170KB gzipped
- first-load CSS <= 90KB gzipped
- optimized images and lazy loading
- real-user monitoring for key routes

SAMPLE COPY TO MATCH

Hero:
“Feed your roadmap. Learn where your time actually goes.”
“BarkBowl is a satirical grocery shelf for features, bugs, refactors, ceremonies, and planning rituals priced in the hours your team will never get back.”

Product card:
“Tiny Ticket Tender Bits — ‘Just one button’ in bite-sized denial.”
“Typical order: 9 p-h.”
“Plain English: Small requests expand once acceptance criteria show up.”

Receipt:
“No money accepted.”
“You burned 21 p-h, roughly 2.6 p-days, or 4.4% of a six-person two-week sprint.”
“Shipping was instant because the work already lived in your calendar.”

Error:
“We couldn’t add that snack right now. Nothing is lost. Try again, or refresh the bowl.”

DOGFOODING PROGRAM PAGE

Explain ring rollout:
- Ring 0: Builder Pack
- Ring 1: Friendly Maintainers
- Ring 2: Cross-Functional Kennel
- Ring 3: Public Yard

For each ring show:
- audience
- success criteria
- metrics required to advance
- rollback trigger

QA AND ACCEPTANCE

Do not mark complete until all are true:
- all nav/footer routes resolve
- all seeded content renders
- cart add/remove/receipt works
- quiz returns correct archetypes
- simulator produces visible educational outputs
- titles/metas/schema/sitemap/robots exist
- keyboard and focus pass on all core paths
- telemetry fires for all core events
- feature flags/rings are wired and testable
- no placeholder shortcodes or staging copy remain
- the site feels like a premium finished product, not a half-seeded prototype
- every major joke is paired with an immediate educational explanation

FINAL DELIVERABLE EXPECTATION

Produce:
- the finished theme and plugin architecture
- seeded content importers
- templates, patterns, and design tokens
- TypeScript modules
- REST controllers
- accessibility-compliant UI behaviors
- telemetry wiring
- launch-ready content across all routes
- QA checklist and acceptance evidence