CartWise/docs/decision-log.md

CartWise Decision Log

Purpose

This file records product, scope, architecture, and delivery decisions for CartWise so a solo founder + AI workflow does not repeatedly revisit the same unresolved questions.

How To Use

• Add a new entry when a decision changes backlog scope, technical direction, or release timing
• Keep entries short and explicit
• Reference related backlog stories in docs/scrum-backlog.md when helpful
• Update an existing entry only to add a superseding decision or revisit trigger

Entry Template

### DEC-XXX - Short title
- Date: YYYY-MM-DD
- Status: Proposed | Accepted | Superseded
- Decision: One-sentence summary
- Reason: Why this was chosen
- Impact: What changes in the backlog, implementation, or release plan
- Revisit Trigger: What would cause this to be reconsidered

Decisions

DEC-001 - MVP target and launch window

• Date: 2026-08-10
• Status: Accepted
• Decision: Target a local MVP completion by September 10, 2026.
• Reason: A one-month deadline forces scope discipline and creates a practical solo-founder release target.
• Impact: Only MVP and P0 backlog work should be treated as launch-critical.
• Revisit Trigger: The MVP cut changes or the launch target date moves.

DEC-002 - Delivery model

• Date: 2026-08-10
• Status: Accepted
• Decision: Use a solo founder + AI delivery model with the founder acting as product owner, reviewer, and primary QA.
• Reason: AI can accelerate implementation, but final product judgment and local verification remain human responsibilities.
• Impact: Backlog items must stay small, explicit, and easy to verify locally.
• Revisit Trigger: Additional human contributors join active development.

DEC-003 - Barcode scanning is out of MVP

• Date: 2026-08-10
• Status: Accepted
• Decision: Barcode scanning, camera workflows, and scan-page work are deferred until after MVP.
• Reason: These features add complexity and are not required for the first launchable grocery-memory workflow.
• Impact: CW-EPIC-04 barcode and scan stories remain Post-MVP or Deferred.
• Revisit Trigger: Core MVP is stable and there is time to add scan functionality.

DEC-004 - External product providers are out of MVP

• Date: 2026-08-10
• Status: Accepted
• Decision: Open Food Facts, USDA, and other external provider integrations are deferred until after MVP.
• Reason: Manual and local-only workflows are sufficient for MVP and reduce dependency risk.
• Impact: Provider-related backlog stories remain Deferred or Post-MVP.
• Revisit Trigger: MVP is complete and product resolution becomes the next highest-value feature.

DEC-005 - SQLite for MVP development

• Date: 2026-08-10
• Status: Accepted
• Decision: Use SQLite for MVP and local development instead of PostgreSQL.
• Reason: SQLite lowers setup friction and is better suited for a fast local-first development loop.
• Impact: Foundation stories should wire SQLite first while keeping a future PostgreSQL path possible.
• Revisit Trigger: Hosted or multi-user production deployment becomes the priority.
• Implementation Note (2026-08-10, CW-STORY-01.2): CartWiseDbContext lives in CartWise.Infrastructure/Data and is wired to SQLite only through InfrastructureServiceCollectionExtensions.AddInfrastructure, via options.UseSqlite(...) and the ConnectionStrings:DefaultConnection setting in appsettings.json. Moving to PostgreSQL later is expected to mean swapping UseSqlite for UseNpgsql and the connection string in that single extension method — no changes anticipated in CartWise.Domain or CartWise.Application.

DEC-006 - Local-first release strategy

• Date: 2026-08-10
• Status: Accepted
• Decision: Build and validate the app locally before any public deployment work.
• Reason: Local-first release reduces operational complexity during MVP delivery.
• Impact: Public hosting, infrastructure, and deployment work are not launch blockers for the current MVP.
• Revisit Trigger: Local MVP is stable and ready for broader testing.

DEC-007 - Shopping mode may be deferred

• Date: 2026-08-10
• Status: Accepted
• Decision: A dedicated shopping mode page is post-MVP unless the standard list page proves insufficient.
• Reason: A mobile-friendly list can satisfy core purchase flow needs with less implementation overhead.
• Impact: CW-EPIC-06 is treated as post-MVP for now.
• Revisit Trigger: MVP list flow cannot support practical in-store use.

DEC-008 - Manual purchase flow is acceptable for MVP

• Date: 2026-08-10
• Status: Accepted
• Decision: Manual purchase entry is acceptable for MVP even if list-to-purchase linkage is simplified at first.
• Reason: Price history and replenishment value can be delivered without sophisticated scan or shopping workflows.
• Impact: Purchase and price stories stay in MVP while more advanced purchase linkage can evolve later.
• Revisit Trigger: Manual purchase entry creates too much friction during testing.