Project Squad Framework · Fieldside Demo
From idea to decision
in a structured sprint.
This page walks through the complete Project Squad framework flow using Fieldside — a fictional community sports club app — as the example project. Every piece of content shown here comes directly from the demo/example-project branch.
⚙
Init — /init-project-squad
Reads _meta/PROJECT_CONTEXT.md and scaffolds all living documents. One command, zero blank files.
S0
Sprint 000 — Foundation
Establishes shared context, documents constraints, and aligns the squad before any feature work begins.
S1
Sprint 001 — Member Onboarding
Seven personas sketch the problem. One decision is made. Elias dissents. The dissent is recorded with a review trigger.
⚡
Spike 001 — Push Notifications
A single question, a qualification test, a 4-hour time box, and a clear yes/no recommendation with conditions.
ℹ
The seven personas live in .squad/project-squad.md and must never be modified. They are the one file that is identical across every project that uses this framework. Specialists in .squad/specialists.md are additive — they extend the squad for specific sprints without replacing any core persona.
Leo Finch
Visual Designer · #1
"Does this feel like us?"
Keeper of the brand. Sees every decision through the lens of visual identity, consistency, and emotional resonance. Will push back on anything generic, off-brand, or visually incoherent. Leads visual direction in the Sketch phase and evaluates prototypes for brand alignment.
Dr. Lena Petrova
Design Engineer · #2
"How will we build, test, and maintain this?"
Bridges design and engineering. Thinks in systems, components, and processes. Asks how a proposed solution fits the design system, what the maintenance overhead is, and whether it can be built with current tooling. Leads Phase 1 (Map) and produces ADRs.
Marcus Thorne
Senior Developer · #3
"What are we NOT building here?"
The long-term thinker. Defines what is out of scope and flags architectural decisions that will be hard to reverse. The voice of restraint and long-term health. Provides architectural boundaries in the Sketch phase and flags long-term risks in the Decide phase.
Kira Sharma
Developer · #4
"What does the implementation actually look like?"
Translates abstract decisions into concrete implementation realities. Identifies integration points, testing challenges, and effort estimates that others miss. The ground truth for "can we actually build this, and how long will it take?"
Dr. Aris Thorne
Strategist · #5
"What is the real problem we are trying to solve?"
The problem reframer. Deeply suspicious of solutions not properly connected to a user need. Consistently asks whether the team is solving the right problem. Leads Phase 1 (Map), generates HMW questions, and leads Phase 4 (Synthesise).
Rowan Vale
Craftsman · #6
"What does this feel like from beginning to end?"
Thinks in end-to-end experiences — not just the screen, but the email notification, the physical touchpoint, the moment of delight or frustration. Brings a holistic, sensory perspective and pushes the team to think beyond the immediate interface.
Mandatory Dissent
Elias Vance
Client (External) · #7
"Does this solve a real problem for my users?"
The external client voice and standing dissenter. His job is to represent the real-world user and challenge assumptions. His dissent must always be recorded in dissent-register.md, even if the team overrules him — because the most common failure mode of a sprint is groupthink. Dissent is a feature, not a bug.
⚑
Why only Elias has Mandatory Dissent: Any persona can raise a concern. But Elias is the only one whose dissent is structurally required — because he is the only one who is not a maker. He has no stake in the solution being buildable, elegant, or on-time. His only stake is whether it solves a real problem for the user. That independence is what makes his challenge worth recording even when the team overrules him.
Alex Mercer
Data Scientist
"What does the data actually tell us?"
Add when sprints involve analytics, personalisation, or decisions where the team is relying on intuition rather than measurement. Produces data quality assessments, statistical significance checks, and measurement frameworks.
Priya Nair
Security & Compliance
"What could go wrong, and who is responsible when it does?"
Add when sprints involve user data, authentication, payments, or PII. Produces threat models, compliance checklists (GDPR, PCI-DSS), and recommended security controls.
Sam Okafor
Content Strategist
"What are we actually saying, and to whom?"
Add when sprints involve onboarding flows, marketing pages, notification copy, or error messages. Produces content audits, tone of voice guidelines, and microcopy recommendations.
Jordan Reeves
Accessibility Specialist
"Who are we leaving out, and why?"
Add when sprints involve new UI components, navigation patterns, or features used by a broad public audience. Produces WCAG compliance checklists and assistive technology test plans.
The framework has three entry points depending on where you are in a project. Every path starts with the same command and ends with the same output: a decision, recorded, with the reasoning preserved.
Starting from zero
1
Write _meta/PROJECT_CONTEXT.md
A single file describing your project: name, stack, known users, initial constraints. This is the only thing you write from scratch. Everything else is generated.
2
Run /init-project-squad
The command reads your context file and scaffolds the full project structure: living documents pre-populated, sprint backlog seeded, dissent register ready. No blank files.
3
Run Sprint 000 — Foundation
Before any feature work: establish shared understanding of who the users are, what the constraints are, and what "good" looks like. The squad speaks. Aris reframes. Elias challenges. Decisions are logged.
4
Run Sprint 001+ — Feature Sprints
Each sprint targets one moment in the user journey. Seven personas sketch the problem. One solution is chosen. Elias's dissent is recorded with a review trigger. A summary.json is written.
⚡
Run Spikes when blocked
One question. A qualification test. A 4-hour time box. An Answer-First output. The recommendation unblocks the next sprint and appends to DECISIONS.md.
New Project
Context → /init → Sprint 000 → Sprint 001+
New Feature
Read living docs → /create-sprint → Sketch → Decide
Uncertainty
One question → /create-spike → Qualify → Recommend
Without these three files, the AI has no memory between sessions. With them, it acts like a senior team member who was in every meeting. The Brain is not documentation — it is the AI's working context. If it is weak, the AI guesses. If it is strong, the AI reasons.
The Rules
Design patterns and architectural standards. Every correction you make to the AI becomes a rule here.
Achieved by
Correcting a mistake → write the correction as a rule. The AI never makes the same mistake twice.
Example: AI built a desktop table. You corrected it. Rule added: "Mobile-First: always use cards, never tables."
The Users
Goals, pain points, and journeys. Not invented — discovered through sprint synthesis.
Achieved by
Mapping a user journey → the insight becomes a persona entry. Ask: "Who is the most stressed person in this system?"
Example: Sprint 000 mapped the secretary's journey. Pain point discovered: "Fears admin burden more than poor features."
The History
Append-only log of every significant choice. Log the fork in the road, not the destination.
Achieved by
Every sprint Decide phase → log the decision and the rejected alternative. The why matters more than the what.
Example: Chose invite links over open registration. Logged: "Rejected public sign-up to prevent spam and preserve secretary control."
How the Brain grows over time
Inputs → Brain
CTX
/init-project-squad reads PROJECT_CONTEXT.md and seeds all three files with your initial knowledge.
SPRINT
Synthesise phase updates PERSONAS.md. Decide phase appends to DECISIONS.md.
SPIKE
Recommendation appends to DECISIONS.md. Open questions feed the next sprint backlog.
FIX
Every correction you make to the AI strengthens PRINCIPLES.md. Mistakes compound into rules.
Brain → Outputs
AI acts like a senior team member who was in every meeting
New developers onboard in minutes, not weeks
Consistent quality across every PR — the rules travel with the project
init-project-squad
/init-project-squad is not a generator — it is a reader. It reads what you know, then creates the structure to capture what you will learn. The command runs once per project and should never need to be run again.
1
Pre-flight: Read _meta/PROJECT_CONTEXT.md
Silently reads your context file. Extracts: project name, stack, known personas, initial principles, open questions. If the file does not exist, prompts you to create it from the template before proceeding.
2
Scaffold the directory structure
Creates research/, research/sprints/, research/spikes/, docs/decisions/, .squad/, and .claude/commands/. No files yet — just the skeleton.
3
Seed the Living Documents
Creates PRINCIPLES.md, PERSONAS.md, and DECISIONS.md pre-populated from your context file. Not placeholder text — real content. The secretary persona, the mobile-first principle, the tech stack decision are all in there from day one.
4
Create the operational files
Creates sprint-backlog.md seeded with the open questions from your context file as sprint candidates. Creates sprint-status.md (empty, ready for Sprint 000). Creates dissent-register.md with the Review Trigger column header.
5
Merge CLAUDE.md
Reads your existing CLAUDE.md (if present) and appends the Project Squad framework rules as a named section. Your project-specific context stays at the top — the framework rules sit below it. The AI reads both.
6
Confirm and recommend Sprint 000
Prints a summary of what was created, confirms the toolkit version (v1.1.0), and recommends running /create-sprint with "Foundation" as the topic. Sprint 000 is not optional.
⚠
The quality of the output depends entirely on the quality of your context file. A thin PROJECT_CONTEXT.md produces thin living documents. Spend 20 minutes on it. The more you put in, the less you have to explain in every subsequent sprint.
ℹ
The context file is the seed. A thin context file produces thin living documents. Spend 20 minutes on it. The more honest and specific you are, the less you will have to explain in every subsequent sprint. The full template is at examples/project-context-template.md.
Section 1
Project Overview
Name, one-line description, North Star goal, the problem it solves today, and what is explicitly out of scope. The out-of-scope field is the most skipped and the most important.
Prompt: "Finish this sentence: This is a _____ that helps _____ do _____."
Section 2
The Users
2–3 real user personas: role, goal, frustration, and a key quote in their voice. Seeds PERSONAS.md. You don't need perfect personas — you need honest ones.
Prompt: "Who is the most stressed person in this system?"
Section 3
Squad Mapping
Optionally map the seven portable personas to real people on your team. The personas do not change — this is for your reference only. If no real counterpart exists, leave it as N/A.
Elias always participates regardless of whether there is a real person mapped to him.
Section 4
Design Principles
Write principles as constraints, not aspirations. Seeds PRINCIPLES.md. You will add more throughout the project — every corrected mistake becomes a rule.
"Mobile-first" is a constraint. "Good UX" is not.
Sections 5 & 6
Known Decisions & Tech Stack
Log any decisions already made and the rejected alternatives. List the tech stack. Seeds DECISIONS.md. Leave blank if not yet decided — Sprint 000 will establish this.
Log the rejected alternative too. That is the part that gets forgotten.
Section 7
Open Questions
Feature questions become sprint candidates. Technical questions become spike candidates. Seeds sprint-backlog.md. You don't need to answer them here — that is what the sprints are for.
Format: "How does [user] [do something]?" or "Can we [capability] without [constraint]?"
The framework is not limited to a single sprint or a single feature. It scales to a full product lifecycle. The key insight is that a large project is simply a user journey with multiple moments — and each moment gets its own sprint. The sprint backlog is the roadmap.
The mental model: map the journey first, assign sprints second
Before you run a single sprint, map the user's journey from first contact to the long-term goal. Each step in that journey is a candidate sprint. Sprint 000 is always first. After that, prioritise by risk — the riskiest, least-understood moment gets the next sprint.
| # |
Moment in the Journey |
Type |
What it produces |
Priority |
| 000 |
Foundation — shared context, stack, principles |
Sprint |
Living docs seeded, team aligned |
Must |
| 001 |
First key user moment — e.g. onboarding |
Sprint |
Validated spec, ADR, dissent logged |
Must |
| S-01 |
Technical question blocking sprint 002 |
Spike |
Recommendation, unblocks next sprint |
Must |
| 002 |
Second key moment — e.g. core feature |
Sprint |
Validated spec, updated PERSONAS.md |
Must |
| 003 |
Third moment — e.g. notifications |
Sprint |
Validated spec, dissent reviewed |
Should |
| 004+ |
Subsequent moments, refinements, edge cases |
Sprint |
Backlog evolves — plan 3–5 ahead only |
Could |
One moment per sprint
Each sprint targets a single moment in the user journey. If you find yourself writing two sprint questions about different moments, split it into two sprints. Focused sprints produce better decisions.
The Brain compounds
Each sprint makes the next one cheaper. Sprint 003 pre-flights read the decisions from Sprint 001 and 002 automatically. By Sprint 005, the AI has deep context and the squad barely needs to re-explain anything.
Spikes run in parallel
A spike does not block a sprint unless the sprint depends on its answer. If a technical question is not on the critical path, run the spike in parallel while the sprint proceeds. Log it in the backlog with a dependency note.
Dissent review triggers fire
As the project grows, overruled dissents from early sprints may become relevant again. The /create-sprint pre-flight scans the dissent register and surfaces any entry whose review trigger matches the upcoming sprint topic.
Choosing the right sprint format
| Format | When to use | Phases | Time |
|---|
| Full Sprint |
Complex features, high-stakes decisions, new territory |
Map → Sketch → Decide → Synthesise |
Half day |
| Lite Sprint |
Lower-stakes decisions, refinements, known territory |
Map → Decide |
1–2 hours |
| Workshop |
Time-pressured, all phases in one session |
Compressed |
2–3 hours |
| Spike |
A specific question is blocking progress |
Qualify → Investigate → Recommend |
4 hours max |
1
Do not modify .squad/project-squad.md — it is the portable constant. The seven personas travel unchanged between every project.
2
First 20 Lines — every output must have YAML frontmatter and a TL;DR within the first 20 lines. Any document can be scanned in seconds.
3
Elias Vance always dissents — his challenge must be recorded in the dissent register even if the team overrules him.
4
One question per spike — multiple questions mean multiple spikes. A spike that tries to answer two things answers neither.
5
summary.json is mandatory — machine-readable output for every sprint and spike. This is the connective tissue the pre-flight checks read.
6
Specialists are additive — .squad/specialists.md extends the team, never replaces core personas.
7
Dissent has a review trigger — every entry in dissent-register.md must include a condition under which it should be revisited.
init-project-squad
ℹ
Before running the command, create _meta/PROJECT_CONTEXT.md from the template. The init command reads it automatically and pre-populates every living document with real content — no blank files, no placeholder text.
PROJECT_CONTEXT.md
You write this
/init-project-squad
Run once
Living Documents
Pre-populated
sprint-backlog.md
Ready for Sprint 000
📁 _meta/
PROJECT_CONTEXT.md ← you create this before init
📁 research/
PRINCIPLES.md
PERSONAS.md
DECISIONS.md
sprint-status.md
sprint-backlog.md
dissent-register.md
📁 .squad/
project-squad.md ← portable constant, never modified
specialists.md ← optional domain roles
📁 .claude/commands/
init-project-squad.md
create-sprint.md
create-spike.md
CLAUDE.md ← merged: project context + framework rules
research/PRINCIPLES.md
Admin-first, mobile-first, no onboarding friction, offline-tolerant. Plus technical principles: pnpm only, no new dependencies without a spike, GDPR by default.
research/PERSONAS.md
Three user personas: Club Secretary ("I just need it to work"), Active Member ("I just want to know when I'm playing"), Lapsed Member ("I'd probably come back if someone made it easy").
research/DECISIONS.md
High-level decision log. Grows with each sprint. Links to full ADRs in docs/decisions/. Currently tracks 4 decisions from Sprint 000 and Sprint 001.
research/dissent-register.md
Every overruled dissent from Elias, with a Review Trigger. The /create-sprint pre-flight scans this before each sprint and surfaces relevant entries automatically.
research/sprint-backlog.md
7 sprint and spike candidates. The /create-sprint and /create-spike commands read this in their pre-flight checks and offer the next candidate automatically.
research/sprint-status.md
Running log of all sprints and spikes. Tracks sprint number, topic, date, status, personas, and folder path. Sprint 000 and Sprint 001 complete; Spike 001 complete.
create-sprint
TL;DR: Foundation sprint to establish shared context, document known constraints, and align the squad on what "good" looks like for Fieldside before any feature work begins.
Long-Term Goal
In 12 months, a club secretary running Fieldside spends less than 30 minutes per week on club admin. Members know when they're playing, whether they've paid, and who else is in the squad — without ever having to ask. Lapsed members find their way back because re-engagement is frictionless.
Sprint Questions
1. Do we have a shared understanding of who our primary users are and what they actually need?
2. Do we have a shared understanding of what "good" looks like on this project?
3. Are there existing constraints or decisions that should be documented before we start building?
How Might We Questions
HMW make the secretary's weekly admin routine feel effortless rather than burdensome?
HMW ensure members always have the information they need without having to ask?
HMW design for the lapsed member without making the active member's experience worse?
HMW build something that works reliably in a muddy field with poor signal?
HMW make the system self-sustaining so it doesn't depend on the secretary remembering to do things?
✓
Sprint 000 output: Tech stack confirmed (Next.js 14, PlanetScale, Sanity, NextAuth.js). Three user personas documented. Four core design principles established. Admin-first principle adopted as the primary design constraint.
create-sprint
ℹ
Pre-flight check in action: Before this sprint ran, /create-sprint read sprint-backlog.md and offered "Member onboarding flow" as the top candidate. It also scanned dissent-register.md — empty at this point, so nothing was surfaced.
TL;DR: How does a new member join Fieldside for the first time — and how do we make it fast enough that they don't give up?
Sprint Challenge
The first time a member uses Fieldside is the highest-risk moment in the product. If onboarding is slow, confusing, or requires too much information, they will abandon it and go back to WhatsApp. We need to design an onboarding flow that gets a member from "I've been sent a link" to "I can see my squad and my next fixture" in under 60 seconds.
Target Moment on the Map
The moment between receiving the invite link and seeing the club dashboard for the first time. This is the make-or-break moment for adoption.
Leo Finch
Visual Designer
"Does this feel like us?"
The invite link is the first brand impression. The landing page should feel warm and specific to their club — the club name, the club colours, and a single clear action. The onboarding flow should feel like a conversation, not a form. One question per screen. The position selector should be a visual pitch diagram — faster, more engaging, and it immediately signals that this app understands football.
Dr. Lena Petrova
Design Engineer
"How will we build, test, and maintain this?"
NextAuth.js supports custom sign-in pages — we can build the invite-link landing page as a standard Next.js page. The one-question-per-screen pattern is achievable with a simple step-based state machine in React. The secretary notification on completion must use a server action, not a client-side event. Client-side events are unreliable on slow connections.
Marcus Thorne
Senior Developer
"What are we NOT building here?"
We are not building a full user profile system in this sprint. Name, email, and playing position only. The data model decision that matters most: a "member" is not the same as a "user". Keep them separate. A user is an auth identity; a member is a club-specific role. This allows the same person to be a member of multiple clubs without duplicate accounts.
Kira Sharma
Developer
"What does the implementation actually look like?"
Secretary triggers invite → server creates record in invites table with token, expiry, used flag → member taps link → middleware validates token → member completes three steps → server creates member record, marks invite used, fires notification. Effort: 3–4 days. The SVG pitch diagram is the wildcard.
Dr. Aris Thorne
Strategist
"What is the real problem we are trying to solve?"
The real problem is not the onboarding flow — it's adoption. The app has to be useful to the secretary before members join. If the secretary can manage fixtures and track payments on their own, they will have a reason to invite members. If the app only becomes useful once members are on it, we have a chicken-and-egg problem.
Rowan Vale
Craftsman
"What does this feel like from beginning to end?"
The onboarding flow is not just a form — it is the first time a member feels like they belong to the club. The invite link email should feel personal, not automated. The three-step flow should feel like a welcome, not a registration. The completion screen should confirm their place in the squad, not just confirm their account. The secretary notification is a moment of delight for the admin — make it feel like something happened.
Mandatory Dissent
Elias Vance
Client
"Does this solve a real problem for my users?"
I want to challenge the invite-link model directly. The secretary has to do something before any member can join. That's a dependency on the least reliable person in the system. The alternative — open registration with a club code — puts the burden on the member, not the secretary. I'm not saying we're wrong. I'm saying we should define a clear trigger for revisiting this if the bet doesn't pay off.
The invite-link model was chosen in Sprint 000 and the team remains confident in it. The GDPR risk of open registration — collecting data from people who may not be genuine club members — is a real constraint, not a hypothetical one.
The User/Member entity separation is adopted as a core data model decision. A user is an auth identity; a member is a club-specific role. This enables multi-club support without duplicate accounts.
⚠ Dissent Recorded — Elias Vance
Challenged the invite-link model on the grounds that it creates a dependency on secretary proactivity. His proposed alternative — open registration with a club code — would reduce per-member secretary burden. Team acknowledged the concern but maintained the invite-link decision on GDPR grounds.
Review Trigger
Revisit if user testing shows that member adoption is below 60% of invited members completing registration, or if the secretary consistently fails to send invites within 48 hours of a new member joining.
↻
How the review trigger works: When Sprint 003 (Fixture Management) runs, the /create-sprint pre-flight will scan dissent-register.md and surface this entry automatically — because Sprint 003 will generate adoption data that could trigger the review condition.
create-spike
The Spike Question
Can we deliver reliable push notifications to club members using a web app (PWA), without building a native iOS/Android app?
Can you confidently estimate the effort required to complete this work?
No → Qualifies
Is this uncertainty actively blocking a decision or a larger piece of work?
Yes → Qualifies
Is the primary goal to gain knowledge, not to ship a feature?
Yes → Qualifies
ℹ
This spike blocks Sprint 003 (Fixture Management). Without knowing whether Web Push is viable, we cannot scope fixture reminder notifications. The spike must complete before Sprint 003 can be planned.
Answer
Yes, with caveats. Web Push via a PWA is viable for Android and desktop. iOS support is available from iOS 16.4+ but requires the user to add the app to their home screen first.
Confidence: Medium · Recommendation: Proceed with PWA push · Time box: 4 hours (completed within limit)
TL;DR: Web Push works on Android and desktop. iOS requires home screen installation (iOS 16.4+). For a club audience, this is acceptable. Proceed with PWA push notifications, but add a home screen prompt to the onboarding flow for iOS users.
| Platform |
Browser |
Web Push Support |
Notes |
| Android |
Chrome |
Full |
Service Worker + Push API fully supported |
| Android |
Firefox / Samsung Internet |
Full |
Supported |
| iOS 16.4+ |
Safari |
Partial |
Requires "Add to Home Screen" — not available in browser tab |
| iOS < 16.4 |
Safari |
None |
Not supported |
| iOS (any) |
Chrome / Firefox |
None |
WebKit restriction — third-party browsers cannot use push |
| Desktop |
Chrome, Firefox, Edge |
Full |
Fully supported |
Conditions on the Recommendation
01
Add an iOS home screen prompt to the onboarding flow — after the member has seen the squad list (the emotional payoff), not before.
02
Always maintain a fallback notification channel (email). Push notifications are a convenience layer, not the primary communication channel.
03
Build subscription expiry detection and re-prompt from the start. An expired subscription that silently fails is worse than no push at all.
Elias Vance — Spike Perspective
"My concern is the iOS user who adds the app to their home screen, then removes it three weeks later. Their push subscription becomes invalid and they stop receiving notifications — and they don't know why. We need a fallback (email or SMS) for users whose push subscription lapses. Don't ship push-only notifications."
Note: Elias's concern became Condition 02 on the recommendation — not a dissent, but a condition. This is the difference between a challenge that changes the outcome and one that is overruled.
ℹ
The /create-sprint and /create-spike commands read this file during their pre-flight checks. If a candidate is ready, they offer it to you before asking you to define a new sprint. You don't have to remember what comes next.
| # |
Type |
Topic |
Priority |
Status |
| 001 |
Sprint |
Member onboarding flow |
High |
Done |
| 002 |
Spike |
Push notifications without a native app? |
High |
Done |
| 003 |
Sprint |
Fixture management — how does a secretary create and publish a fixture? |
High |
Candidate |
| 004 |
Sprint |
Payment and subs — how does a member pay, and how does the secretary track it? |
High |
Candidate |
| 005 |
Spike |
Which payment provider supports low-volume recurring subscriptions at minimal cost? |
Medium |
Candidate |
| 006 |
Sprint |
Re-engagement — how do we bring lapsed members back? |
Medium |
Candidate |
| 007 |
Sprint |
Admin dashboard — what does a secretary actually need to see at a glance? |
Medium |
Candidate |
↻
The /create-sprint pre-flight scans the Review Trigger column before each sprint. If a trigger condition matches the upcoming sprint's topic, it surfaces the entry automatically — so overruled concerns from Sprint 001 can reappear when Sprint 008 hits the relevant territory.
⚠ Sprint 001 — Invite-Link Model · Elias Vance
"An invite-link model assumes the secretary is proactive enough to send invites. In practice, they won't. Members will try to sign up independently and hit a wall. We're optimising for a problem we don't have (spam registrations) at the cost of the problem we do have (low adoption)."
Review Trigger
Revisit if user testing in Sprint 003 or later shows that member adoption is below 60% of invited members completing registration.
ℹ
summary.json is what the pre-flight checks read to understand the project's history without loading every document into context. It is the connective tissue of the framework. Every sprint and spike must produce one.
{
"type": "spike",
"spike_id": "spike-001",
"question": "Can we deliver reliable push notifications to club members using a web app (PWA), without building a native iOS/Android app?",
"date_completed": "2026-03-02",
"answer": "Yes, with caveats. Web Push via a PWA is viable for Android and desktop. iOS 16.4+ requires home screen installation.",
"recommendation": "proceed-with-pwa-push",
"confidence": "medium",
"key_finding": "~85% coverage. Email fallback essential. Implementation: 4.5–5.5 days.",
"conditions": [
"Add iOS home screen prompt to onboarding flow",
"Always maintain email as a fallback notification channel",
"Build subscription expiry detection from the start"
],
"unblocks": ["sprint-003-fixture-management"],
"open_questions": [
"What is the right re-subscription UX?",
"Third-party push service vs. manage subscriptions ourselves?"
]
}