Skip to main content

Slice overview

Helm is built as 11 vertical slices. Each slice ships a complete user-facing feature: schema + endpoints + UI + tests + docs. We pick one slice, ship it, pick the next.

Drafted from planning · v0.1

The slices​

#SliceStatusDepends on
1Identity & AuditBuilt (gating + chain-verify cron remaining)—
2CustomersBuilt1
3Inventory & TaxSchema + ETL + read-only UI1
4Service TicketsBuilt1, 2, 3
5Transactions & PaymentsSchema + ETL; UI pending1, 2, 3, 4
6Purchase OrdersSchema + ETL; UI pending1, 3
7RentalsSchema only1, 2
8Trade-In & ConsignmentSchema only1, 2, 3
9Online OrdersSchema only1, 2, 3, 5
10MarketingSchema only1, 2
11AI Conversation MemorySchema only1, all data

Why this order​

Slice 1 first because it's foundational. Auth, audit, and permissions thread through everything else. The audit-everywhere wiring needs to land before mutations start happening at scale.

Slice 2 next because customers are the central FK; almost every other slice references them. Built first lets every subsequent slice assume customers exist.

Slice 4 (Service Tickets) before slice 5 (Transactions) is the surprise. Service tickets are the core of a bike shop's day — more cognitive load on operators, more business value, more migration data to validate. Building tickets first proves the patterns. Cashout-from-ticket then becomes the first transaction path.

Slice 3 (Inventory) is concurrent with slice 4 in practice — service tickets need inventory access for parts lines. The schema is in place; the UI for direct inventory management lags.

Slices 5-10 are roughly independent and can be ordered by business value. Sales (slice 5) is the natural next priority post-tickets. Rentals/Trades/Orders/Marketing follow.

Slice 11 (AI) last because it benefits from existing data — the AI Support bubble's grounding is over what shops actually have, not what they will eventually have.

What "shipped" means per slice​

A slice is "shipped" when:

  • Schema migrations for all involved tables are in migrations/*.sql
  • Backend endpoints are written, tested, deployed; all CRUD + lifecycle transitions covered
  • Frontend screens are built; replace any mockup-only stand-ins
  • Tests cover the core flows (unit + integration)
  • Documentation in this bible — entity pages, lifecycle if applicable, slice page (this section)
  • Migration scripts (when applicable) for inbound AIM data are in migrate_aim.py
  • The shop is using it in production for the relevant operations

The last bullet is the real bar. "Specced and coded but not used" is not shipped.

Cross-slice concerns​

Some concerns thread through every slice and need attention at slice 1:

  • Audit-everywhere — every mutation writes audit. The helper lives in slice 1; every subsequent slice uses it.
  • Idempotency keys — every external write. Adapter pattern enforces it.
  • In-situ editing affordances — every slice's UI follows the helm-editable chassis.
  • Permissions — every endpoint is gated by screen-permissions middleware.
  • Observability — every endpoint emits structured logs.
  • PII handling — every PII field in every slice respects the privacy principle.

These are not "later slices to build." They're invariants enforced from the first slice forward.

Re-ordering and re-prioritization​

The slice order is a default, not a contract. Mid-sequence we may re-order based on shop needs. For example, if Swicked is sitting on $20K of trade-in inventory unrecorded, slice 8 (Trade-In) might leapfrog slice 5 (Sales) for them specifically. The branch model (deployment topology) allows per-shop feature ordering when needed.

Slices 12 and beyond​

Slices 12–25 are documented in the roadmap at docs/overview/roadmap.md. Individual slice pages will be created when each slice is specified per the slice-development pattern. Until then the roadmap is the canonical home for "what's planned" — including the architectural pins (ADR-0024: Serial numbers as first-class entities) that must land before specific slices build.

See also​