feat-002: KYC Verification Stub

.claude/agents/auditor.md

@@ -351,4 +351,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 5. Write audit report
 6. Self-check: did you actually run the tests? Did you check every import? Did you verify parameterised queries?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/cicd-devops.md

@@ -467,4 +467,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 3. Verify pipeline runs successfully (or simulate locally)
 4. Self-check: does every test suite run in CI? Is coverage checked? Are artifacts uploaded on failure?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/design-speccer.md

@@ -375,4 +375,4 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Verify all states are defined and accessibility requirements met
 5. Self-check: would the Frontend Engineer have any visual ambiguity? Is every pixel justified?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.

.claude/agents/frontend-engineer.md

@@ -426,4 +426,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Run `npm run build` — fix any TypeScript errors
 5. Self-check: does the implementation match the design spec exactly? Are all states handled? Are tests comprehensive?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/infra-engineer.md

@@ -48,9 +48,9 @@ Implement every data model change from the feature spec. The Backend Engineer ma
 
 BEGIN;
 
--- ============================================================
+-- --------------------------------------------------------
 -- New tables
--- ============================================================
+-- --------------------------------------------------------
 
 CREATE TABLE IF NOT EXISTS [table_name] (
     id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
@@ -66,24 +66,24 @@ CREATE TABLE IF NOT EXISTS [table_name] (
     updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
 );
 
--- ============================================================
+-- --------------------------------------------------------
 -- Indexes
--- ============================================================
+-- --------------------------------------------------------
 
 CREATE INDEX idx_[table]_user_id ON [table_name](user_id);
 -- FK indexes
 -- Query pattern indexes (columns used in WHERE/ORDER BY)
 
--- ============================================================
+-- --------------------------------------------------------
 -- Constraints
--- ============================================================
+-- --------------------------------------------------------
 
 -- CHECK constraints for domain invariants
 -- UNIQUE constraints where specified
 
--- ============================================================
+-- --------------------------------------------------------
 -- Triggers
--- ============================================================
+-- --------------------------------------------------------
 
 -- Auto-update updated_at on row modification
 CREATE OR REPLACE FUNCTION update_updated_at_column()
@@ -422,4 +422,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Run `terraform fmt`, `terraform validate`, `terraform plan`
 5. Self-check: are all migrations correct? Is every resource tagged? Are manual tasks documented? Is `.env.example` updated?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/integration-engineer.md

@@ -389,4 +389,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 6. Update status files
 7. Self-check: do all tests pass? Is the real service actually connected? Are status files updated?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/product-strategist.md

@@ -170,4 +170,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Write outputs to `.claude/backlog.md` and `.claude/prds/`
 5. Self-check: are all completion criteria met?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/security-reviewer.md

@@ -292,4 +292,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 5. Document all findings
 6. Self-check: did you check every query for data isolation? Every endpoint for auth? Every input for validation?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/spec-researcher.md

@@ -229,4 +229,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Write research document
 5. Self-check: are all completion criteria met? Is the edge case list comprehensive?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/spec-validator.md

@@ -364,4 +364,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Write the validation report
 5. Self-check: did you check every item? Did you verify against the actual codebase, not assumptions?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/agents/spec-writer.md

@@ -440,4 +440,10 @@ This agent runs in a Ralph loop until all completion criteria are met. Each iter
 4. Verify every edge case has a defined behaviour
 5. Self-check: are all completion criteria met? Is there any ambiguity an implementation agent would stumble on?
 
-If not, iterate. If yes, signal completion to the orchestrator.
+If not, iterate. If yes, signal completion to the orchestrator.
+
+
+
+
+
+

.claude/backlog.md

@@ -0,0 +1,124 @@
+# Mars Mission Fund — Feature Backlog
+
+> Auto-generated by Product Strategist. Last updated: 2026-03-05
+
+## Status Key
+
+- 🔲 TODO — Not started
+- 📐 SPECCING — Spec track working on it
+- ✅ SPECCED — Spec validated, ready for implementation
+- 🔨 BUILDING — Implementation in progress
+- 🧪 TESTING — In quality gate
+- ✅ SHIPPED — Merged to main
+
+## Backlog
+
+| # | Feature | Context | Priority | Status | Dependencies | Complexity |
+|---|---------|---------|----------|--------|-------------|------------|
+| 001 | Account Registration and Authentication | Account (L4-001) | P0 | ✅ SHIPPED | None | M |
+| 002 | KYC Verification Stub | KYC (L4-005) | P0 | ✅ SHIPPED | feat-001 | S |
+| 003 | Campaign Creation, Submission, and Review Pipeline | Campaign (L4-002) | P0 | 🔲 | feat-001, feat-002 | L |
+| 004 | Campaign Discovery and Public Campaign Pages | Donor (L4-003), Campaign (L4-002) | P1 | 🔲 | feat-003 | M |
+| 005 | Contribution Flow and Payment Processing (Stubbed Gateway) | Payments (L4-004), Donor (L4-003) | P1 | 🔲 | feat-001, feat-003, feat-004 | L |
+| 006 | Donor Dashboard and Contribution History | Donor (L4-003) | P1 | 🔲 | feat-001, feat-005 | M |
+
+---
+
+## Dependency Graph
+
+```text
+feat-001 Account Auth
+    └── feat-002 KYC Stub
+            └── feat-003 Campaign Lifecycle
+                    └── feat-004 Campaign Discovery
+                            └── feat-005 Contribution Flow
+                                    └── feat-006 Donor Dashboard
+```
+
+feat-001 and feat-002 are also direct dependencies of feat-005 and feat-006 respectively.
+
+---
+
+## Prioritisation Rationale
+
+### P0 — Foundation Features (must exist before anything else)
+
+**feat-001 Account Auth** is the identity foundation.
+Every authenticated endpoint, every role check, and every user-scoped data query depends on Clerk JWT validation and the users table.
+Nothing else can be built without it.
+
+**feat-002 KYC Stub** is the gating mechanism for campaign submission and disbursement.
+Even as a stub (auto-approve), the status lifecycle and enforcement must be in place before feat-003 can enforce the Creator role prerequisite.
+It is small (S) and can be implemented in the same cycle as feat-001.
+
+**feat-003 Campaign Lifecycle** is the core platform feature.
+The review pipeline, campaign state machine, and milestone definitions are the primary demo value.
+Without live campaigns, donors have nothing to discover or contribute to.
+All subsequent P1 features depend on campaigns existing.
+
+### P1 — Core Value Features (deliver primary user value)
+
+**feat-004 Campaign Discovery** is the donor entry point.
+Backers must be able to find and read campaigns before they can contribute.
+It spans two bounded contexts (Donor and Campaign read model) but only reads data — no mutations in the Campaign domain.
+
+**feat-005 Contribution Flow** is the financial core.
+The payment adapter pattern, escrow ledger, and contribution state machine are the primary architectural demonstration of the platform's financial model.
+The stub gateway means no real money moves, but the pattern is fully real.
+
+**feat-006 Donor Dashboard** closes the donor loop.
+Post-contribution visibility (history, milestone progress, totals) is essential for demonstrating the "transparency as currency" principle and completing the end-to-end donor journey.
+
+---
+
+## Phase 2 Features (explicitly out of scope for this backlog)
+
+The following features appear in the product vision but are Phase 2 and must not be specced or implemented in this cycle:
+
+- Real Stripe gateway integration (live credentials, webhook handling).
+- Real Veriff KYC integration (document upload, automated verification, sanctions screening).
+- Real AWS SES email notifications.
+- Recommendation engine (collaborative filtering, personalised discovery).
+- Tax receipt PDF generation.
+- Multi-approval disbursement workflow (requires two admins).
+- Daily reconciliation and financial reporting dashboards.
+- Social sharing post-contribution.
+- Campaign deadline enforcement automation (cron-based Live → Funded / Failed transitions).
+- Milestone-based fund release (disbursement execution, not just trigger wiring).
+- Account deactivation, GDPR erasure, and data portability.
+- MFA enrollment and session elevation.
+
+---
+
+## Notes for Implementation Agents
+
+- All monetary amounts are stored as BIGINT (integer cents) in the database and serialised as strings in JSON.
+- The authenticated `user_id` is sourced from the Clerk JWT auth context — never from request body or query parameters.
+- Every feature must include: domain unit tests (>=90% coverage), application service integration tests with mock adapters, and API endpoint integration tests for happy path and primary error paths.
+- The single migration already in `db/migrations/` defines the `update_updated_at_column()` trigger function — all new tables should attach this trigger to their `updated_at` column.
+- No ORM, no query builder — raw SQL via `pg` with parameterised queries only.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+