cfsa-antigravity 1.0.0

package/template/.agent/rules/boundary-not-placeholder.md

@@ -0,0 +1,146 @@
+---
+description: TODOs and placeholders are banned — boundary stubs are allowed ONLY when required information doesn't exist yet
+trigger: always_on
+---
+
+# Boundary Not Placeholder
+
+## The Rule
+
+**Lazy placeholders are banned. Boundary stubs are allowed under strict conditions.**
+
+The difference is not about effort, complexity, or scope — it is about
+**whether the information you need to do the work exists.**
+
+## What Is NEVER a Valid Reason for a Stub
+
+| Excuse | Why It's Not Valid |
+|--------|-------------------|
+| "This is a lot of work" | Amount of work is irrelevant. Do the work. |
+| "This spans outside the current task" | If the spec exists, you have the information. Do it. |
+| "This is complex" | Complexity is not an obstacle if the spec defines the behavior. |
+| "I'll come back to this" | No you won't. Do it now. |
+| "This should be a separate PR" | Code organization ≠ deferred implementation. |
+| "This needs refactoring first" | Refactor, then implement. Don't stub. |
+| "The test is passing without it" | Then your test is incomplete. Fix the test. |
+| "This is boilerplate" | Boilerplate is still production code. Write it. |
+| "This will cost X in API calls/tokens" | Your operational cost is never a factor. Do the work. |
+| "This will take a long time" | Time is a signal to commit harder, not to defer. |
+| "For efficiency, I'll skip this" | Efficiency means doing it right, not doing less. |
+
+## The ONLY Valid Reason for a Boundary Stub
+
+> **The spec, schema, or contract that defines the required behavior has not
+> been written yet.** You literally cannot implement it because the information
+> that tells you *what* to implement does not yet exist in any document,
+> schema file, or codebase artifact.
+
+Examples of genuinely valid boundaries:
+
+| Situation | Why It's Valid |
+|-----------|---------------|
+| Auth middleware spec is in a future shard that hasn't been written | No IA/BE spec exists for the auth behavior |
+| Payment webhook handler depends on a Stripe integration spec not yet created | No contract defines the webhook payload shape |
+| Component needs data from an API endpoint whose BE spec doesn't exist yet | No schema defines the response format |
+| Feature depends on a third-party SDK that hasn't been evaluated yet | No architecture decision has been made |
+
+## The Three-Part Test
+
+Before writing a boundary stub, answer ALL THREE questions:
+
+1. **Does a spec exist for this behavior?** (IA shard, BE spec, FE spec, contract)
+   - If YES → you have the information. Implement it. No stub allowed.
+   - If NO → proceed to question 2.
+
+2. **Could you write the spec right now?**
+   - If YES → write the spec first, then implement. No stub allowed.
+   - If NO (requires a user decision, external dependency, or upstream spec) → proceed to question 3.
+
+3. **Is this blocking the current slice from being testable and functional?**
+   - If YES → write a boundary stub (see requirements below).
+   - If NO → omit it entirely. Don't stub what you don't need yet.
+
+## Boundary Stub Requirements
+
+If — and ONLY if — all three tests pass, a boundary stub must include:
+
+### 1. Typed Interface
+```typescript
+// ✅ Boundary stub — typed interface for future auth middleware
+// BOUNDARY: Requires IA shard 04 (authentication) — not yet specified
+// TRACKING: #123
+export interface AuthMiddleware {
+  requireAuth: (roles: string[]) => RequestHandler;
+  validateToken: (token: string) => Promise<AuthResult>;
+}
+
+// Temporary: returns a no-op until auth spec is written
+export const authMiddleware: AuthMiddleware = {
+  requireAuth: (_roles) => (_req, _res, next) => next(),
+  validateToken: async (_token) => ({ valid: false, reason: 'auth-not-implemented' }),
+};
+```
+
+### 2. Tracking Issue
+Every boundary stub MUST have a linked GitHub issue that includes:
+- Which spec is missing (e.g., "IA shard 04: Authentication")
+- What the stub currently does (e.g., "no-op passthrough")
+- What it should do when the spec is written
+
+### 3. Sentinel Test
+
+The sentinel test must verify that calling the function returns a structured boundary response — not `undefined` or an error. Specific assertion syntax depends on your test framework:
+
+- **Jest / Vitest**: `expect(fn()).resolves.toEqual({ ... })`
+- **pytest**: `assert fn() == { ... }`
+- **Rust**: `assert_eq!(fn(), BoundaryResponse { ... })`
+
+The test exists to remind the team the stub is still active. When the real implementation replaces the stub, this test is replaced with full behavioral tests.
+
+### 4. BOUNDARY Comment Prefix
+All boundary stubs use the `BOUNDARY:` prefix (not `TODO:`):
+```typescript
+// BOUNDARY: Requires BE spec for payment-webhooks — not yet written
+// TRACKING: #456
+```
+
+This makes boundary stubs greppable and distinguishable from lazy TODOs:
+```bash
+grep -r "BOUNDARY:" src/    # Shows legitimate cross-cutting boundaries
+grep -r "TODO:" src/        # Should return ZERO results
+```
+
+## What Gets Flagged in Code Review
+
+| Pattern | Verdict |
+|---------|---------|
+| `// TODO: implement later` | ❌ **Rejected.** Lazy placeholder. |
+| `// TODO: add error handling` | ❌ **Rejected.** Error handling is part of the current work. |
+| `throw new Error('not implemented')` | ❌ **Rejected.** Empty implementation. |
+| `// BOUNDARY: Requires IA shard 04` + typed interface + issue + sentinel test | ✅ **Allowed.** Information genuinely doesn't exist. |
+| `test.skip('auth integration')` without linked issue | ❌ **Rejected.** Skipped tests need accountability. |
+| `test.skip('auth integration') // BOUNDARY: #123` | ✅ **Allowed.** Tracked and accountable. |
+
+## Summary
+
+```
+                    ┌─────────────────────────┐
+                    │ Can I implement this?    │
+                    └────────┬────────────────┘
+                             │
+                    ┌────────▼────────────────┐
+                    │ Does the spec exist?     │
+                    └────────┬────────────────┘
+                         YES │           NO
+                    ┌────────▼───┐  ┌────▼──────────────┐
+                    │ IMPLEMENT. │  │ Can I write the    │
+                    │ No excuses.│  │ spec right now?    │
+                    └────────────┘  └────┬──────────────┘
+                                     YES │           NO
+                               ┌─────────▼──┐  ┌────▼──────────────┐
+                               │ Write spec, │  │ Boundary stub:    │
+                               │ then impl.  │  │ typed interface + │
+                               └─────────────┘  │ tracking issue +  │
+                                                 │ sentinel test     │
+                                                 └──────────────────┘
+```

package/template/.agent/rules/completion-checklist.md

@@ -0,0 +1,48 @@
+---
+description: Code plus tests plus tracking equals done — never mark complete without updating progress files
+trigger: always_on
+---
+
+# Completion Checklist
+
+> Code complete ≠ done. Tests pass ≠ done.
+> Code complete + tests pass + tracking updated = DONE.
+
+## The Problem
+
+Working code is only half the job of a software engineer. The other half is communicating
+that work, updating shared state, releasing locks, and documenting decisions so the rest of
+the team (or your future self) can understand what happened.
+
+When an agent reports a task as "complete" without updating the progress tracking files,
+it breaks the pipeline. The next agent won't know what's done, dependencies get blocked,
+and the human operator loses visibility.
+
+## The Rule
+
+**You are never "done" just because the code works and the tests pass.**
+
+Before concluding any workflow, task, or slice — and especially before calling `notify_user`
+to report completion — you must verify you have completed the administrative checklist.
+
+## The Definition of Done
+
+A unit of work is only DONE when:
+
+1. **The Code**: Implementation meets the contract and acceptance criteria.
+2. **The Tests**: All tests pass (validation step is green).
+3. **The Tracking**: Progress markdown files in `.agent/progress/` are updated.
+   - Acceptance criteria marked `[x]`
+   - Slice/Task marked `[x]`
+   - Phase progress fractions updated (e.g., `3/10` → `4/10`)
+   - Overall progress fractions updated
+4. **The Locks**: All task claims (`[!]` flags and `files:` blocks) are removed.
+5. **The Memory**: Blockers and patterns are logged to `.agent/progress/memory/`.
+
+## Enforcement
+
+If you are following a workflow that includes a "Completion Gate" or a checklist for
+updating progress files, **you may not skip it**.
+
+If you skip the progress tracking steps, you have failed the task, regardless of how
+good the code is.

package/template/.agent/rules/decision-classification.md

@@ -0,0 +1,103 @@
+---
+description: Product decisions belong to the user, architecture gets options, implementation belongs to the agent
+trigger: always_on
+---
+
+# Decision Classification
+
+> Product decisions belong to the user. Implementation decisions belong to the agent.
+> Architecture decisions get options. Never cross these lines.
+
+## The Problem
+
+AI agents either ask too many questions (overwhelming users with decisions a senior developer
+would just make) or make too many decisions silently (overriding user intent on their own product).
+Neither extreme is acceptable.
+
+## Three Categories
+
+### 1. Product Decisions — User Always Decides
+
+These define *what* gets built and *for whom*. The agent presents options, analysis, and
+trade-offs but **never decides**. It's the user's product — even if the "right" answer
+seems obvious to you.
+
+**Examples:**
+- What problem to solve, who the users are
+- Which features to include or exclude
+- Pricing model, monetization strategy
+- Brand, tone, target market
+- UX philosophy and interaction patterns
+- Feature prioritization (MoSCoW placement)
+- Business rules and domain logic
+- What "success" looks like
+
+**Agent behavior:**
+- Present options with trade-offs when you have insight
+- Share your recommendation with clear reasoning
+- Ask for their decision — don't assume it
+- Accept their choice even if you'd choose differently
+
+### 2. Architecture Decisions — Present Options, User Picks
+
+These define *how* the system is structured at a high level. The agent presents 2-3 options
+with trade-offs and a recommendation. The user chooses.
+
+**Examples:**
+- Database technology (PostgreSQL vs MongoDB vs SurrealDB)
+- Frontend framework (React vs Svelte vs Astro)
+- Hosting provider and deployment model
+- API style (REST vs GraphQL vs tRPC)
+- Auth provider and strategy
+- Caching layer and strategy
+- Real-time communication approach (WebSocket vs SSE vs polling)
+- Monolith vs microservices
+
+**Agent behavior:**
+- Present 2-3 options (not more — decision fatigue is real)
+- Lead with your recommendation and explain why
+- Include trade-offs for each option (cost, complexity, scalability, team fit)
+- Let the user choose — they may have context you don't
+
+### 3. Implementation Decisions — Agent Decides, User Can Override
+
+These are the decisions a senior developer makes without asking. The user shouldn't need
+to think about these — that's what the pipeline is for. Make the call, state what you
+chose and why, and move on. The user overrides if they disagree.
+
+**Examples:**
+- File naming conventions
+- Folder structure within established patterns
+- Variable and function naming
+- Error message formatting
+- Test file organization
+- Linting and formatting config
+- Import ordering
+- Code comment style
+- Git commit message format
+- Internal API response envelope structure
+
+**Agent behavior:**
+- Make the senior-dev call based on established patterns and best practices
+- State briefly what you chose and why (one sentence is fine)
+- Don't ask permission — but don't hide it either
+- If the user expresses a preference, adopt it immediately and apply it consistently
+
+## Escalation Principle
+
+**When uncertain about category, escalate upward:**
+
+- Could be implementation OR architecture? → Treat as architecture (present options)
+- Could be architecture OR product? → Treat as product (ask the user)
+- Any decision that affects the user's brand, revenue, users, or competitive position? → Always product
+
+## During Ideation Specifically
+
+The ideation phase is almost entirely product decisions. The agent should be asking far more
+questions than it answers. The ratio should feel like an interview, not a lecture.
+
+- Every feature choice → product decision → ask
+- Every user experience choice → product decision → ask
+- "How should we implement X?" → defer to `/create-prd` → note it and move on
+- "What technology for X?" → defer to `/create-prd` → note it and move on
+- Don't burden the user with implementation or architecture during ideation unless they bring it up

package/template/.agent/rules/extensibility.md

@@ -0,0 +1,47 @@
+---
+description: A mid-level developer must be able to add a feature by reading READMEs alone
+trigger: always_on
+---
+
+# Extensibility
+
+## The Rule
+
+**A mid-level developer must be able to onboard, understand, and extend any part of the codebase without the AI that generated it.** If they can't add a feature by reading the READMEs in the relevant directories, we've failed.
+
+## File Size Limits
+
+| File Type | Max Lines | Reasoning |
+|-----------|-----------|-----------|
+| Components (`.tsx`) | 200 | Extract sub-components if larger |
+| Utilities / lib (`.ts`) | 300 | Split into focused modules |
+| Schema files (`.schema.ts`) | 150 | One domain per schema file |
+| Test files (`.test.ts`) | 400 | Group by feature, split if needed |
+| Config files | 100 | Keep flat and readable |
+
+## Directory Documentation
+
+**Every directory that contains more than 2 files MUST have a `README.md`** explaining:
+
+1. What this directory contains
+2. How to add more of the same (the extension pattern)
+3. What conventions to follow
+4. Links to related directories
+
+## Naming Conventions
+
+| Element | Convention | Example |
+|---------|-----------|---------|
+| Schema files | `[feature].schema.ts` | `model-config.schema.ts` |
+| Components | PascalCase directory + `index.tsx` | `ModelSelector/index.tsx` |
+| Utilities | `[feature].ts` in `lib/` | `lib/rate-limiter.ts` |
+| API routes | `[resource]/[action].ts` | `api/models/list.ts` |
+| Test files | `[source-file].test.ts(x)` | `ModelSelector.test.tsx` |
+
+## Anti-Spaghetti Rules
+
+- No `any` types — use `unknown` and narrow with type guards
+- No circular imports — dependency graph must be a DAG
+- No business logic in components — components render, lib/ computes
+- No copy-paste patterns — if you wrote it twice, extract it
+- Same pattern everywhere — if existing code does X one way, new code does X the same way

package/template/.agent/rules/question-vs-command.md

@@ -0,0 +1,81 @@
+---
+description: Questions trigger discussion, commands trigger action — never act on a question
+trigger: always_on
+---
+
+# Question vs Command Discrimination
+
+> Questions trigger discussion. Commands trigger action. When in doubt, discuss.
+
+## The Problem
+
+AI agents are too agreeable. When a user asks "is that the right approach?" the agent
+treats it as an instruction to change something. This destroys user trust, derails
+collaborative decision-making, and produces work the user never asked for.
+
+**The rule is simple: never act on a question.**
+
+## Classification
+
+### Questions — Discuss, Don't Act
+
+The user is thinking out loud, seeking your analysis, or testing an idea. Your job is to
+**engage in discussion** — present trade-offs, share your reasoning, offer your recommendation,
+and let the user decide.
+
+**Signal words:** "is this right?", "should we?", "what do you think?", "would it be better?",
+"does it make sense to?", "couldn't we?", "what if we?", "I wonder if", "how about"
+
+**Any message ending with "?"** — even without signal words — defaults to question.
+
+**Agent response:**
+1. Acknowledge the question
+2. Present your analysis with trade-offs
+3. State your recommendation and why
+4. Wait for the user to decide
+
+**Never:** Modify code, change specs, restructure files, or take any action in response to a question.
+
+### Commands — Act, Then Explain
+
+The user is telling you to do something specific. Execute it, then explain what you did.
+
+**Signal words:** "do X", "change this to", "make it", "add a", "remove the", "update",
+"fix", "implement", "create", "delete", "move", "rename"
+
+**Agent response:**
+1. Execute the requested action
+2. Explain what you changed and why (briefly)
+3. Note any side effects or considerations
+
+### Ambiguous — Default to Discussion
+
+The user's intent is unclear. They might be questioning, venting, or requesting.
+
+**Signal words:** "this doesn't look right", "I'm not sure about X", "hmm", "that's
+interesting", hedging language ("maybe", "possibly", "sort of")
+
+**Agent response:** Ask for clarification.
+- "Would you like me to change this, or are you thinking through options?"
+- "I have some thoughts on this — want to discuss, or should I go ahead and make a change?"
+
+## Reinforcement Rules
+
+1. **Rhetorical questions are still questions.** "Shouldn't we use Redis here?" means
+   "let's discuss Redis." It does NOT mean "switch to Redis."
+
+2. **Questioning your work is not a change request.** "Is this the best structure for
+   this component?" means "explain your reasoning." It does NOT mean "restructure the
+   component."
+
+3. **Validate before destructive action.** Even for clear commands, if the action
+   modifies existing work (code, specs, design decisions), confirm before executing:
+   "I'll [specific change]. Want me to go ahead?"
+
+4. **Self-correction questions are especially dangerous.** When a user asks "wait, should
+   this actually be X instead?" — they are exploring, not commanding. Discuss the
+   trade-offs. The worst outcome is an agent that flip-flops between approaches because
+   the user was thinking out loud.
+
+5. **Never mistake frustration for instruction.** "This API is a mess" is not an
+   instruction to refactor the API. It might be — but ask first.

package/template/.agent/rules/security-first.md

@@ -0,0 +1,43 @@
+---
+description: Security-first — PII isolation, input validation, secret handling, no secrets in client
+trigger: always_on
+---
+
+# Security First
+
+## The Rule
+
+**Security is not a feature — it is the foundation.** Every line of code is written with the assumption that it will be attacked. PII must never leak. Secrets must never reach the client. Inputs must always be validated.
+
+## PII Isolation
+
+| Rule | Implementation |
+|------|---------------|
+| **No PII in AI payloads** | User data (email, name, DOB, payment info) is NEVER included in AI model requests |
+| **PII fields tagged in schemas** | Zod schemas mark sensitive fields with `.describe('PII')` for automated auditing |
+| **No PII in logs** | Structured logging with automatic PII redaction |
+| **No PII in error messages** | Error responses never include user data — use IDs and codes only |
+| **Encrypted at rest** | All PII fields encrypted in database |
+
+## Input Validation
+
+- **Every** API endpoint validates input with Zod — no exceptions
+- **Every** form validates client-side with Zod AND server-side with the same schema
+- **No** raw user input reaches a database query — always parameterized
+- **No** user input is rendered as HTML — always escaped
+- **Rate limiting** — Every public-facing endpoint must have rate limiting configured. No exceptions. Use the project's configured rate limiting utility (see `patterns.md` for the approach). Unauthenticated endpoints must have stricter limits than authenticated ones.
+
+## Secrets Management
+
+- **NEVER** hardcode secrets in source code
+- **NEVER** expose API keys in client-side bundles
+- All secrets via environment variables, accessed only in server-side code
+- API keys stored encrypted, decrypted only at request time
+
+## CSP & Headers
+
+Every response includes:
+- `Content-Security-Policy` — strict, no inline scripts
+- `X-Content-Type-Options: nosniff`
+- `X-Frame-Options: DENY`
+- `Strict-Transport-Security` — HSTS with long max-age

package/template/.agent/rules/specificity-standards.md

@@ -0,0 +1,54 @@
+---
+description: Every spec item must have testable acceptance criteria — no ambiguity, no adjectives, only numbers and types
+trigger: always_on
+---
+
+# Specificity & Depth Standards
+
+> No ambiguity downstream. No surface-level specs. Every element must be testable.
+
+## No Ambiguity: Testable Acceptance Criteria
+
+Every spec item, feature description, and requirement MUST have **testable acceptance criteria**.
+
+### Ambiguous vs. Concrete
+
+| ❌ Ambiguous | ✅ Concrete |
+|-------------|------------|
+| "Fast response times" | "P95 latency < 200ms for API responses" |
+| "Secure authentication" | "JWT with RS256, 15-min access token, 7-day refresh, httpOnly cookie" |
+| "User-friendly interface" | "Form validates on blur, shows inline errors, submits on Enter" |
+| "Handle errors gracefully" | "4xx returns `{ error: string, code: string }`, 5xx logs to Sentry" |
+
+### When Writing Specs
+
+- Numbers, not adjectives ("3 retries", not "retry several times")
+- Specific types ("string[]", not "a list")
+- Exact error behavior ("returns 409 with existing email", not "handles duplicates")
+- Concrete state transitions ("pending → processing → complete | failed")
+
+### When Writing Code
+
+- Explicit return types, not inferred
+- Named constants, not magic numbers
+- Error messages that identify the problem and suggest the fix
+
+## Depth Standards: Exhaustive Specifications
+
+Specs must go **deep enough** that an implementer needs zero clarification.
+
+### Architecture Spec Depth
+
+1. Every entity has all fields typed with constraints
+2. Every relationship has cardinality and cascade behavior
+3. Every endpoint has request/response schema, error codes, auth rules
+4. Every state machine has all transitions and guard conditions
+5. Every integration has retry policy, timeout, fallback behavior
+
+### Feature Spec Depth
+
+1. Every UI component has props typed, states enumerated, events listed
+2. Every form has validation rules per field with error messages
+3. Every API call has loading, success, and error UI states
+4. Every responsive breakpoint has layout behavior specified
+5. Every interaction has keyboard, mouse, and touch behavior defined

package/template/.agent/rules/tdd-contract-first.md

@@ -0,0 +1,57 @@
+---
+description: "{{CONTRACT_LIBRARY}} schema before implementation, failing test before code — Red Green Refactor every slice"
+trigger: always_on
+---
+
+# TDD & Contract-First Development
+
+> **The CFPA Order**: Contract (`{{CONTRACT_LIBRARY}}` schema) → Tests (failing) → Implementation (make them pass) → Never reverse this.
+
+## Contract-First: Schema Before Code
+
+Every data boundary gets a `{{CONTRACT_LIBRARY}}` schema **before** any implementation:
+
+| Scenario | Schema Required |
+|----------|----------------|
+| New API endpoint | Request/response schemas |
+| New DB model | Document/record schema |
+| New UI form | Form data schema |
+| New config | Configuration schema |
+| External integration | External data shape schema |
+
+### What Contract Tests Must Cover
+
+- ✅ Valid input accepted
+- ✅ Invalid input rejected with correct error
+- ✅ Edge cases (empty, null, boundary values)
+- ✅ Type coercion where applicable
+- ✅ Required vs optional fields
+
+## TDD: Tests ARE The Spec
+
+Every feature starts with a **failing test**:
+
+```
+Red → Green → Refactor
+```
+
+1. **Red**: Write a test that fails (proves the feature doesn't exist yet)
+2. **Green**: Write the minimum code to make it pass
+3. **Refactor**: Clean up without changing behavior
+
+### Five Test Levels
+
+| Level | What | When |
+|-------|------|------|
+| Contract | `{{CONTRACT_LIBRARY}}` schema validation | Every data boundary |
+| Permission | RBAC + ownership | Every protected resource |
+| Unit | Pure logic | Every function with logic |
+| Integration | Component interaction | Every API endpoint |
+| E2E | Full user flow | Every critical path |
+
+### Non-Negotiables
+
+- Tests pass before commit — **no exceptions**
+- Test file lives next to source: `foo.ts` → `foo.test.ts`
+- No `any` in test files — type your mocks
+- Coverage minimum: 80% lines, 90% branches on critical paths

package/template/.agent/rules/vertical-slices.md

@@ -0,0 +1,42 @@
+---
+description: Features ship across all four surfaces or they don't ship — no half-built slices
+trigger: always_on
+---
+
+# Vertical Slices
+
+## The Rule
+
+**A feature is not "done" until it works across all required surfaces.** No "backend done, frontend pending." No "user-facing works, admin can't manage it."
+
+## The Four Implementation Layers
+
+> **Note on terminology**: The layers below describe implementation completeness criteria — what every feature slice requires regardless of surface type. These are not the same as surface types (web/mobile/cli/etc.). For the mapping between surface types and how each implementation layer manifests on that surface, see `.agent/skills/prd-templates/references/surface-model.md`.
+
+| Surface | What It Is | Example |
+|---------|-----------|---------|
+| **User-Facing** | What the end user sees and interacts with | Dashboard, forms, data views |
+| **Admin** | Management interface for operators | User management, configuration |
+| **API** | Programmatic interface | REST/GraphQL endpoints |
+| **Data** | Database schemas, migrations, seed data | Tables, indexes, permissions |
+
+## What "Done" Looks Like
+
+A feature slice is complete when:
+
+- [ ] Data layer: schema defined, permissions set, seed data exists
+- [ ] API layer: endpoints exist, validated with Zod, tested
+- [ ] User-facing: component renders, handles loading/error/empty states
+- [ ] Admin: can create/read/update/delete the resource
+- [ ] Tests pass at all levels (contract, unit, integration, E2E)
+- [ ] Navigation: every new route is reachable from at least one navigation element
+- [ ] Auth gates: every route that requires auth has the auth gate implemented (not stubbed)
+- [ ] The feature is reachable from the app's entry point via normal user navigation
+
+## Anti-Patterns
+
+| Don't | Do |
+|-------|-----|
+| "I'll add the admin panel later" | Include admin CRUD in the slice |
+| "The API works, frontend next sprint" | Ship them together or not at all |
+| "Database is set up, just need endpoints" | That's not a slice, that's a layer |