Single-page readiness and feature-map view

CorePOS Project Dashboard

One compact CorePOS planning view with a high-level dashboard and the deeper Living Feature Map in the same static page.

Generated 2026-05-18T11:45:34.358Z Thailand time 18 May 2026, 18:45 ICT Source commit fc5b2e9eba0b Primary share link ./PROJECT_DASHBOARD.html
Dashboard tabFeature Map tabDashboard PDFFeature Map PDFDocs
Use the tabs for the compact view. Print/PDF expands both sections sequentially.
Clapham Cycle core go-live 72% On track for 2026-08-01. 22 tracked launch fundamentals
Full product/commercial 63% Includes wider rollout maturity and add-on scope.
Bolt-on maturity 50% QuickBooks, rental/hire, widgets, suppliers, and other optional packages.
Own-shop trial use 70% Immediate controlled single-shop trial readiness across operationally relevant areas.
Future ideas 1 item Parked outside current Clapham Cycle core scope. Open the parked list
Long-term platform completion 72% Weighted completion across the tracked platform feature map.
Current snapshot

Readiness at a glance

Clapham Cycle core go-live 72%
Single-shop production readiness 71%
Full product/commercial completion 63%
Bolt-on maturity 50%
Implementation completion 79%
Broader commercial rollout 73%
Long-term platform completion 72%

Clapham Cycle core go-live is deliberately narrower than full product/commercial maturity. Bolt-ons and future ideas do not lower the core score unless Thomas explicitly moves them into launch scope.

Soft go-live target

Yes, at the current recent rate the core scope still fits inside the target window.

Current status: On track

Projected threshold date 2026-06-20
Schedule position 42 days ahead of target
Target 2026-08-01
Days remaining 75
Core gap 13%
Estimated time to threshold 33 days

Confidence band: 4 weeks to 6 weeks.

Last 30 days snapshot

Commits 799
PR / merge signals 597
Roadmap events 90
Net changed lines 369,168
Reason: The current heuristic completion window fits inside the time remaining to the soft go-live target.

External single-store pilot planning starts only after 3-6 months stable Clapham Cycle operation. From the target date, that means 2026-11-01 to 2027-02-01, subject to real stability evidence.

Scope breakdown

What counts toward the current launch score

Switch between the current Clapham core launch scope, the later commercial expansion scope, and the bolt-ons or parked work that should not dilute the core percentage.

POS / till / retail workflow

Operational / Staff Workflow
Active Hardening
80% progress 12% of core 2 modules
Progress 80%
Scope share 12%
Modules 2
POS, till, in-store payments, receipts, quotations, layawaysRefunds, exchanges, gift cards, liabilities, and stored value

Workshop UX and behaviour audit

Operational / Staff Workflow
Built, Needs Hardening
76% progress 7% of core 1 modules
Progress 76%
Scope share 7%
Modules 1
Workshop jobs, estimates, approvals, parts, collection, print

Stocktake and inventory accuracy

Operational / Staff Workflow
Built, Needs Hardening
72% progress 6% of core 1 modules
Progress 72%
Scope share 6%
Modules 1
Inventory, stock movements, stocktake, transfers, replenishment

Procurement and receiving maturity

Operational / Staff Workflow
Active Hardening
72% progress 6% of core 1 modules
Progress 72%
Scope share 6%
Modules 1
Procurement, purchase orders, receiving, supplier returns

Diagnostics, support packs, and operational readiness

Operational / Staff Workflow
Built, Needs Hardening
72% progress 6% of core 1 modules
Progress 72%
Scope share 6%
Modules 1
Deployment, diagnostics, support packs, backups, integrity

Online workshop booking

Customer Facing
Active Hardening
72% progress 5% of core 1 modules
Progress 72%
Scope share 5%
Modules 1
Workshop diary, scheduler, capacity, and online workshop booking

Financial reporting, store analysis, BI, and management dashboards

Active Hardening
Active Hardening
74% progress 5% of core 1 modules
Progress 74%
Scope share 5%
Modules 1
Financial reporting, store analysis, BI, and management dashboards

Cash-up, daily close, trade close, cash oversight

Active Hardening
Active Hardening
78% progress 5% of core 1 modules
Progress 78%
Scope share 5%
Modules 1
Cash-up, daily close, trade close, cash oversight

Customer bike lifecycle CRM

Bike-shop-specific
Built, Needs Hardening
73% progress 5% of core 1 modules
Progress 73%
Scope share 5%
Modules 1
CRM, customer management, customer bikes, and service context

Supplier / Madison integration

Operational / Staff Workflow
Active Hardening
70% progress 5% of core 1 modules
Progress 70%
Scope share 5%
Modules 1
Supplier integration foundation and Madison baseline path

Permissions and sensitive action hardening

Operational / Staff Workflow
Foundation Exists
66% progress 5% of core 1 modules
Progress 66%
Scope share 5%
Modules 1
Roles, permissions, login, PIN auth, sensitive-action controls

Clapham Cycle launch rehearsal, live data setup, and acceptance sign-off

Planning
Planning
35% progress 5% of core 1 modules
Progress 35%
Scope share 5%
Modules 1
Clapham Cycle launch rehearsal, live data setup, and acceptance sign-off

Communication Centre: email, SMS, WhatsApp

Customer Facing
Built, Needs Hardening
66% progress 4% of core 1 modules
Progress 66%
Scope share 4%
Modules 1
Customer communication basics and account-visible communication history

System configuration, first-run onboarding, dashboard settings

Built, Needs Hardening
Built, Needs Hardening
70% progress 4% of core 1 modules
Progress 70%
Scope share 4%
Modules 1
System configuration, first-run onboarding, dashboard settings

Rota, staff scheduling, closed days, working hours

Built, Needs Hardening
Built, Needs Hardening
66% progress 4% of core 1 modules
Progress 66%
Scope share 4%
Modules 1
Rota, staff scheduling, closed days, working hours

Staff records and staff directory

Foundation Exists
Foundation Exists
78% progress 3% of core 1 modules
Progress 78%
Scope share 3%
Modules 1
Staff records and staff directory

Google Business Profile / Reviews / Maps

Customer Facing
Foundation Exists
64% progress 3% of core 1 modules
Progress 64%
Scope share 3%
Modules 1
Store Info, opening hours, public business presence, basic Google Business Profile foundation

Staff performance reporting

Built, Needs Hardening
Built, Needs Hardening
88% progress 3% of core 1 modules
Progress 88%
Scope share 3%
Modules 1
Staff performance reporting

Verification / multi-agent tooling

Platform / Commercial
Trial Ready
88% progress 3% of core 1 modules
Progress 88%
Scope share 3%
Modules 1
Release verification, merge readiness, PR process, dashboard publishing

Web builder / templates / embeddable widgets

Customer Facing
Foundation Exists
78% progress 2% of core 1 modules
Progress 78%
Scope share 2%
Modules 1
Clapham Cycle Web Builder site replacement

Stripe/payment trust

Platform / Commercial
Active Hardening
75% progress 2% of core 1 modules
Progress 75%
Scope share 2%
Modules 1
Stripe online payments, public payment status, refunds, reconciliation
Work-rate

Recent delivery signals

Confidence High
30-day commits 799 commits
Approx PR/merge signals 597 signals
Roadmap events 90 events
History note: Approximation based on full local origin/main history, including merge commits and squash-merge-style PR subjects where detectable.
  • 7-day commits: 317 commits
  • 14-day commits: 644 commits
  • 30-day roadmap events: 90 events
  • Changed lines (30d): +394,765 / -25,597 (net 369,168)
LOC summary

Current size and likely range

Headline LOC 598,903
Predicted final range 783,487 to 1,340,519 LOC

LOC source: cloc . --exclude-dir=node_modules,dist,build,.git

LOC remains a size and complexity signal, not a quality score.

Top gaps

Current blockers

  • Workshop UX and behaviour audit: A single workshop readiness audit is not yet codified, so UX debt is spread across several surfaces. high
  • Procurement and receiving maturity: Supplier API ordering, supplier returns/RMA, supplier documents, and procurement accountability still need more operational polish. high
  • Supplier / Madison integration: Live sync, supplier API ordering, and normalization maturity are still intentionally incomplete. high
  • Permissions and sensitive action hardening: Sensitive action review is still distributed across many modules rather than a single hardening ledger. high
  • Diagnostics, support packs, and operational readiness: Support-safe troubleshooting flows still need tighter packaging for real trial use. high
  • Track My Bike / Workshop Progress View: Portal polish, customer wording, and broader regression coverage still need hardening before it feels fully trial-safe. high
  • Communication Centre: email, SMS, WhatsApp: Channel reliability, support tooling, and operator trust signals still need more maturity than the raw transport foundation. high
  • Customer account / portal: Confirmed rental booking readback and storefront order-history readback are account-only and view-only; rental self-service, public confirmation, secure readback tokens, customer-visible receipt/invoice controls, and broader longitudinal account history remain future work. high
Recommended next tasks

Best next planning moves

  • Workshop UX and behaviour audit: Define a workshop hardening checklist covering queue, job detail, check-in, bookings, collection, and portal handoff. high
  • Workshop UX and behaviour audit: Add a compact workshop regression bundle for the highest-risk operator flows. high
  • Procurement and receiving maturity: Turn the procurement gap audit into a living maturity checklist with explicit completion criteria. high
  • Procurement and receiving maturity: Add targeted regression coverage for discrepancy and exception-resolution paths. high
  • Supplier / Madison integration: Run supervised Madison/procurement pilot sessions and use readiness decisions, the operating dashboard, and bounded evidence reports to decide whether narrow manager-led limited use remains justified. high
  • Permissions and sensitive action hardening: Map the highest-risk manager/admin actions into an explicit permissions hardening checklist. high
  • Diagnostics, support packs, and operational readiness: Keep the dashboard’s trial-readiness section concise as diagnostics, integrity, and support-pack maturity continue to grow. high
  • Track My Bike / Workshop Progress View: Add a focused portal hardening checklist covering progress wording, approvals, attachments, and reply flows. high
  • Communication Centre: email, SMS, WhatsApp: Translate post-service follow-up consent, suppression, review-request wording, Google separation, and approval policy into explicit product-data requirements before any outbound workflow is considered. high
  • Communication Centre: email, SMS, WhatsApp: Clarify the maturity ladder for workshop notifications versus broader omnichannel communication. high
Newest ideas

Worth keeping in view

  • Communication Centre: email, SMS, WhatsApp: Track communication maturity by channel trust, orchestration depth, and customer self-service coverage.
  • Customer account / portal: Split portal maturity into identity, self-service, and ongoing customer relationship stages.
  • Customer bike lifecycle CRM: Create a bike-lifecycle maturity band that combines reminders, history, portal access, and workshop continuity.
  • Customer-facing storefront: Track storefront maturity by browse/catalogue, checkout, fulfilment, and post-purchase support.
  • Deployment / Windows / Caddy / production serving: Treat deployment readiness as its own recurring review lane rather than burying it inside docs.
  • Diagnostics, support packs, and operational readiness: Track support-bundle completeness as a first-class maturity signal beside implementation.
  • Google Business Profile / Reviews / Maps: Add a dedicated Google presence maturity lane only after controlled posting has operational evidence or public local-marketing value becomes real.
  • HR personnel foundation add-on: Keep Problem Cycle-specific bonus calculation separate from the reusable commercial HR module unless a configurable framework is deliberately commissioned.
Core fundamentals behind the 72%

These are the tracked modules currently counted into Clapham Cycle core go-live. The weighted average of their progress makes up the headline core percentage.

Tracked modules 22
Current average 72%
Highest progress 88%
Lowest progress 35%

Clapham Cycle launch rehearsal, live data setup, and acceptance sign-off

No linked feature card
Planning
Progress 35%
Launch share 5%
Progress toward launch-ready 35%
Share of the core basket 5%

Cash-up, daily close, trade close, cash oversight

No linked feature card
Active Hardening
Progress 78%
Launch share 5%
Progress toward launch-ready 78%
Share of the core basket 5%

CRM, customer management, customer bikes, and service context

Customer bike lifecycle CRM
Built, Needs Hardening
Progress 73%
Launch share 5%
Progress toward launch-ready 73%
Share of the core basket 5%

Customer communication basics and account-visible communication history

Communication Centre: email, SMS, WhatsApp
Built, Needs Hardening
Progress 66%
Launch share 5%
Progress toward launch-ready 66%
Share of the core basket 5%

Financial reporting, store analysis, BI, and management dashboards

No linked feature card
Active Hardening
Progress 74%
Launch share 5%
Progress toward launch-ready 74%
Share of the core basket 5%

Inventory, stock movements, stocktake, transfers, replenishment

Stocktake and inventory accuracy
Built, Needs Hardening
Progress 72%
Launch share 6%
Progress toward launch-ready 72%
Share of the core basket 6%

POS, till, in-store payments, receipts, quotations, layaways

POS / till / retail workflow
Active Hardening
Progress 82%
Launch share 7%
Progress toward launch-ready 82%
Share of the core basket 7%

Procurement, purchase orders, receiving, supplier returns

Procurement and receiving maturity
Active Hardening
Progress 72%
Launch share 6%
Progress toward launch-ready 72%
Share of the core basket 6%

Refunds, exchanges, gift cards, liabilities, and stored value

POS / till / retail workflow
Built, Needs Hardening
Progress 77%
Launch share 5%
Progress toward launch-ready 77%
Share of the core basket 5%

Roles, permissions, login, PIN auth, sensitive-action controls

Permissions and sensitive action hardening
Foundation Exists
Progress 66%
Launch share 5%
Progress toward launch-ready 66%
Share of the core basket 5%

Rota, staff scheduling, closed days, working hours

No linked feature card
Built, Needs Hardening
Progress 66%
Launch share 4%
Progress toward launch-ready 66%
Share of the core basket 4%

Staff performance reporting

No linked feature card
Built, Needs Hardening
Progress 88%
Launch share 3%
Progress toward launch-ready 88%
Share of the core basket 3%

Store Info, opening hours, public business presence, basic Google Business Profile foundation

Google Business Profile / Reviews / Maps
Foundation Exists
Progress 64%
Launch share 3%
Progress toward launch-ready 64%
Share of the core basket 3%

Supplier integration foundation and Madison baseline path

Supplier / Madison integration
Active Hardening
Progress 70%
Launch share 5%
Progress toward launch-ready 70%
Share of the core basket 5%

System configuration, first-run onboarding, dashboard settings

No linked feature card
Built, Needs Hardening
Progress 70%
Launch share 4%
Progress toward launch-ready 70%
Share of the core basket 4%

Workshop diary, scheduler, capacity, and online workshop booking

Online workshop booking
Active Hardening
Progress 72%
Launch share 6%
Progress toward launch-ready 72%
Share of the core basket 6%

Workshop jobs, estimates, approvals, parts, collection, print

Workshop UX and behaviour audit
Built, Needs Hardening
Progress 76%
Launch share 7%
Progress toward launch-ready 76%
Share of the core basket 7%

Release verification, merge readiness, PR process, dashboard publishing

Verification / multi-agent tooling
Trial Ready
Progress 88%
Launch share 3%
Progress toward launch-ready 88%
Share of the core basket 3%

Staff records and staff directory

No linked feature card
Foundation Exists
Progress 78%
Launch share 4%
Progress toward launch-ready 78%
Share of the core basket 4%

Stripe online payments, public payment status, refunds, reconciliation

Stripe/payment trust
Active Hardening
Progress 75%
Launch share 2%
Progress toward launch-ready 75%
Share of the core basket 2%
Parked future ideas (1 item)

These items are intentionally parked outside the current Clapham Cycle launch scope, so they do not reduce the core go-live score unless their classification changes.

These are rough planning heuristics, not committed estimates. They use the current repo size, recent delivery pace, and how early each idea still is.

Promotions, vouchers, loyalty, advanced discounting

No linked feature card yet
Planning

Outside Clapham Cycle core go-live unless Thomas explicitly adds it.

Estimated size Large
Heuristic LOC 14,307-29,714
Heuristic time 4.1 months to 6.2 months
Share of total product 5%
Current gap: No full promotion, loyalty, voucher, or marketing-discount engine should be assumed from support docs alone.

Next decision: Decide whether promotions/loyalty enter a later commercial phase or remain parked.

Scope classification inventory

Clapham Cycle core completion only moves when scope is explicitly classed as Clapham Cycle core. Bolt-ons and future ideas must not silently lower the core go-live score.

Module Scope Status Clapham Cycle Commercial Bolt-on
Clapham Cycle launch rehearsal, live data setup, and acceptance sign-off LAUNCH_BLOCKING_GAP Planning Launch-blocking governance gap for the 2026-08-01 soft go-live target. Reusable launch process for external pilots later. Not a bolt-on
Clapham Cycle Web Builder site replacement LAUNCH_BLOCKING_GAP Built, Needs Hardening Explicitly in Clapham Cycle go-live scope: the CorePOS-generated website is intended to replace the existing Clapham Cycle website after controlled readiness and migration work. Provides the first real proof case for the later commercial Web Builder add-on. Not a generic bolt-on for Clapham Cycle go-live; broader Web Builder packaging for future stores remains a bolt-on/commercial add-on.
Cash-up, daily close, trade close, cash oversight CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for end-of-day operation. Required for every store. Not a bolt-on
CRM, customer management, customer bikes, and service context CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle retail and workshop continuity. Required for bike-shop differentiation. Not a bolt-on
Customer communication basics and account-visible communication history CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required at basic level for workshop and customer follow-up. Required for customer-service maturity. Not a bolt-on
Deployment, diagnostics, support packs, backups, integrity CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required before a real shop trial. Required before any external pilot. Not a bolt-on
Financial reporting, store analysis, BI, and management dashboards CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for daily shop management and confidence. Required for every store; advanced analytics can become add-on scope later. Not a bolt-on
Inventory, stock movements, stocktake, transfers, replenishment CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle stock confidence. Required for every store. Not a bolt-on
POS, till, in-store payments, receipts, quotations, layaways CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for Clapham Cycle soft go-live. Required for every store. Not a bolt-on
Procurement, purchase orders, receiving, supplier returns CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for core stock replenishment and supplier workflow. Required for every bike shop. Not a bolt-on
Refunds, exchanges, gift cards, liabilities, and stored value CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for controlled shop operation, especially liability review. Required for wider rollout trust. Not a bolt-on
Roles, permissions, login, PIN auth, sensitive-action controls CORE_FUNDAMENTAL_NEEDS_HARDENING Foundation Exists Required for safe staff operation. Required for rollout and support. Not a bolt-on
Rota, staff scheduling, closed days, working hours CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required where booking capacity depends on working patterns. Required for rollout; advanced HR/payroll remains out of scope. Not a bolt-on
Staff performance reporting CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Useful for launch visibility and manager coaching; attribution review, drilldowns, product classification, and cost-snapshot foundations now exist, but formal pay/incentive decisions still need policy sign-off. Commercial management feature with bike-shop-specific retail, workshop, line attribution, review workflow, scorecards, and add-on reporting now maturing. Not a bolt-on
Store Info, opening hours, public business presence, basic Google Business Profile foundation CORE_FUNDAMENTAL_NEEDS_HARDENING Foundation Exists Core public-presence foundation; advanced review/marketing automation is not launch scope. Commercially important local-presence trust layer. Not a bolt-on
Supplier integration foundation and Madison baseline path CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Core as a capability, but live automation is not required for day-one use. Commercial differentiator and paid-connector foundation. Additional supplier connectors can become paid add-ons.
System configuration, first-run onboarding, dashboard settings CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required to make the trial reproducible. Required for external onboarding later. Not a bolt-on
Workshop diary, scheduler, capacity, and online workshop booking CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required as a core workshop scheduling capability; embed packaging is not launch-blocking. Required for commercial trust and customer-facing maturity. Not a bolt-on
Workshop jobs, estimates, approvals, parts, collection, print CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle. Required for every bike-shop rollout. Not a bolt-on
Release verification, merge readiness, PR process, dashboard publishing CORE_FUNDAMENTAL Trial Ready Required for release safety, though not a shop-floor feature. Required for maintainable product operations. Not a bolt-on
Staff records and staff directory CORE_FUNDAMENTAL Foundation Exists Required for staff access and operational records. Required for every store. Not a bolt-on
HQ, multi-location, location governance COMMERCIAL_HARDENING Foundation Exists Not required for single-store Clapham Cycle go-live beyond safe defaults. Important for later multi-store rollout. Not a bolt-on
Persistent customer account, profile/preferences, workshop portal unification, rental readback COMMERCIAL_HARDENING Built, Needs Hardening Helpful for customer service, but not a blocker for core in-shop operation. Important for wider customer-facing product maturity. Not a bolt-on
Stripe online payments, public payment status, refunds, reconciliation COMMERCIAL_HARDENING Active Hardening Supporting for Clapham Cycle; not required for a POS-only soft launch unless Thomas chooses online payments for day one. Required for commercial online/payment trust. Not a bolt-on
Customer-facing storefront, website checkout, online orders BOLT_ON Foundation Exists Not required for Clapham Cycle core go-live. Important later commercial/customer-facing product area. Bolt-on / commerce package candidate.
HR personnel foundation and future payroll BOLT_ON Foundation Exists Outside Clapham Cycle core go-live. Optional HR bolt-on foundation now includes personnel files, review queue, candidate offers, lifecycle event snapshots, regenerated-link controls, withdrawal evidence, and new-starter capture; payroll remains future specialist work. Paid add-on candidate.
Quote Approval public widget BOLT_ON Foundation Exists Widget packaging is not counted toward Clapham Cycle core until Thomas explicitly adds it. Merged customer-facing widget maturity for wider rollout. Bolt-on / paid add-on candidate.
Rental / hire internal platform for bikes and bike boxes BOLT_ON Built, Needs Hardening Explicitly not required for Clapham Cycle core go-live unless Thomas adds it to launch scope. Bike-shop differentiator and bolt-on candidate. Bolt-on / paid add-on candidate.
Rental / hire public request, status, widget flow, account and secure-link readback BOLT_ON Foundation Exists Not required for Clapham Cycle core go-live. Useful customer-facing bolt-on. Bolt-on / paid add-on candidate.
Rental / hire staff booking amendments BOLT_ON Foundation Exists Not counted for Clapham Cycle core readiness because rental is bolt-on scope. Merged bolt-on hardening for rental operations. Bolt-on / paid add-on candidate.
Website builder, richer public widgets, template publishing BOLT_ON Foundation Exists Commercial Web Builder packaging remains outside generic Clapham core scoring; the Clapham-specific generated website replacement is tracked separately as go-live scope. Commercial add-on / packaging area. Bolt-on / paid add-on candidate.
Additional supplier connectors beyond Madison baseline PAID_ADD_ON Planning Outside Clapham Cycle core go-live. Paid supplier connector expansion after Madison/general sync foundations are proven. Paid add-on candidate.
Advanced analytics beyond core financial/store analysis PAID_ADD_ON Foundation Exists Outside Clapham Cycle core go-live beyond basic reports. Potential premium analytics add-on. Paid add-on candidate.
Advanced Google Reviews, review requests, marketing automation, Maps/Places depth PAID_ADD_ON Planning Outside Clapham Cycle core go-live. Potential paid local-marketing add-on after public presence foundation is stable. Paid add-on candidate.
Phone system / telephony integration PAID_ADD_ON Foundation Exists Outside Clapham Cycle core go-live. Optional paid add-on candidate. Paid add-on candidate.
QuickBooks integration, mapping, posting, reconciliation controls PAID_ADD_ON Active Hardening Not required for Clapham Cycle core go-live unless Thomas explicitly adds it to day-one scope. Important paid add-on / accounting trust feature. Paid add-on candidate.
External single-store pilot after Clapham stability NOT_STARTED Planning Must not precede 3-6 months stable Clapham Cycle operation. Next rollout stage after Clapham Cycle proves stable. Not a bolt-on
Promotions, vouchers, loyalty, advanced discounting FUTURE_IDEA_OUT_OF_CURRENT_SCOPE Planning Outside Clapham Cycle core go-live unless Thomas explicitly adds it. Future retail growth idea. Future add-on possibility.
Detailed LOC breakdown
Area LOC Files
Backend 203,634 476
Frontend 166,333 297
Scripts 125,103 334
Print Agent 2,893 24
E2E 8,146 24
Prisma 13,367 182
Tracked areas total 519,476 1,337

Headline project LOC is 598,903. The named rows above cover the main implementation areas and may not include every other tracked file in the repo.

Full velocity details
  • Reference: origin/main
  • 7-day commits: 317 commits
  • 14-day commits: 644 commits
  • 30-day commits: 799 commits
  • Approx PR-like subjects: 308 signals
  • Merge commits detected: 289 merge commits
  • Roadmap events detected: 90 events
  • Changed lines: +394,765 / -25,597 (net 369,168)
Estimate caveats and readiness windows

Clapham Cycle soft go-live

On track for 2026-08-01. Estimated core gap closure: 4 weeks to 6 weeks.

External single-store pilot

Only after stable Clapham Cycle operation: 2026-11-01 to 2027-02-01 from target, if operation is stable.

Long-term platform completion

4 weeks to 6 weeks

Broader commercial rollout

5 weeks to 1.8 months

Single-shop production readiness is shown above as a current maturity score. The current heuristic time model is still more defensible for own-shop trial use, broader rollout, and longer-term platform completion than for a separate single-shop production delivery date.

  • Estimates are heuristic and based on current maturity gaps plus recent local git cadence, not guaranteed delivery dates.
  • PR/integration counts are approximated from local git subjects and may still miss some private or unusually titled workflows.
  • Open PRs are reported as in-progress and are not counted as merged readiness until they land on main.
  • Clapham Cycle core completion excludes bolt-ons, paid add-ons, future ideas, and open PRs unless Thomas explicitly moves them into launch scope.
  • LOC is a size/complexity signal, not a quality metric.
  • This dashboard is strongest where repo evidence is explicit and weaker where maturity still depends on operator practice or rollout trust.
  • The first version does not yet use historical feature-map snapshots, so time estimates rely on current-state heuristics rather than measured maturity deltas.
  • Headline LOC follows the cloc baseline only when cloc is available on the local machine; otherwise it falls back to a clearly labelled approximation.
  • Scope classification is a governance layer: new ideas do not change Clapham Cycle core completion unless their classification and weights explicitly put them into core launch scope.
Full feature maturity table
Feature Status Category Maturity
Verification / multi-agent tooling Trial Ready Platform / Commercial 84%
Customer account / portal Built, Needs Hardening Customer Facing 80%
Supplier / Madison integration Active Hardening Operational / Staff Workflow 80%
Procurement and receiving maturity Active Hardening Operational / Staff Workflow 79%
Track My Bike / Workshop Progress View Built, Needs Hardening Customer Facing 77%
POS / till / retail workflow Active Hardening Operational / Staff Workflow 76%
Stripe/payment trust Active Hardening Platform / Commercial 76%
QuickBooks/accounting trust Active Hardening Platform / Commercial 74%
Communication Centre: email, SMS, WhatsApp Built, Needs Hardening Customer Facing 73%
Deployment / Windows / Caddy / production serving Active Hardening Operational / Staff Workflow 72%
Diagnostics, support packs, and operational readiness Built, Needs Hardening Operational / Staff Workflow 72%
Customer bike lifecycle CRM Built, Needs Hardening Bike-shop-specific 72%
Stocktake and inventory accuracy Built, Needs Hardening Operational / Staff Workflow 70%
Workshop UX and behaviour audit Built, Needs Hardening Operational / Staff Workflow 66%
Permissions and sensitive action hardening Foundation Exists Operational / Staff Workflow 61%
Web builder / templates / embeddable widgets Foundation Exists Customer Facing 93%
Rental / bike box hire internal platform Built, Needs Hardening Bike-shop-specific 85%
Online workshop booking Active Hardening Customer Facing 76%
Service reminders Built, Needs Hardening Bike-shop-specific 75%
Customer-facing storefront Foundation Exists Customer Facing 71%
Workshop service history and customer portal Built, Needs Hardening Bike-shop-specific 71%
Managed printing / labels / print agent Built, Needs Hardening Platform / Commercial 66%
Google Business Profile / Reviews / Maps Foundation Exists Customer Facing 63%
Rental / hire customer-facing flow Foundation Exists Customer Facing 62%
Multi-location / HQ Foundation Exists Platform / Commercial 54%
HR personnel foundation add-on Foundation Exists Platform / Commercial 47%
Support agent / staff help system Foundation Exists Platform / Commercial 46%

Use the Feature Map tab for the category-by-category evidence, gaps, and next-task detail.

Raw limitations and notes
  • This dashboard is strongest where repo evidence is explicit and weaker where maturity still depends on operator practice or rollout trust.
  • The first version does not yet use historical feature-map snapshots, so time estimates rely on current-state heuristics rather than measured maturity deltas.
  • Headline LOC follows the cloc baseline only when cloc is available on the local machine; otherwise it falls back to a clearly labelled approximation.
  • Scope classification is a governance layer: new ideas do not change Clapham Cycle core completion unless their classification and weights explicitly put them into core launch scope.
CorePOS Living Feature Map

Feature-by-feature maturity in one place

Use this tab for the deeper evidence-backed view: scope classification, category roll-ups, top gaps, ideas, next tasks, and the collapsible feature detail underneath.

Clapham Cycle core 72% Narrow soft go-live scope only.
Full product/commercial 63% Includes wider rollout and add-on maturity.
Bolt-on maturity 50% Optional/premium packages.
Future ideas 1 item Outside current scope.
Scope classification inventory

Clapham Cycle core completion only moves when scope is explicitly classed as Clapham Cycle core. Bolt-ons and future ideas must not silently lower the core go-live score.

Module Scope Status Clapham Cycle Commercial Bolt-on
Clapham Cycle launch rehearsal, live data setup, and acceptance sign-off LAUNCH_BLOCKING_GAP Planning Launch-blocking governance gap for the 2026-08-01 soft go-live target. Reusable launch process for external pilots later. Not a bolt-on
Clapham Cycle Web Builder site replacement LAUNCH_BLOCKING_GAP Built, Needs Hardening Explicitly in Clapham Cycle go-live scope: the CorePOS-generated website is intended to replace the existing Clapham Cycle website after controlled readiness and migration work. Provides the first real proof case for the later commercial Web Builder add-on. Not a generic bolt-on for Clapham Cycle go-live; broader Web Builder packaging for future stores remains a bolt-on/commercial add-on.
Cash-up, daily close, trade close, cash oversight CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for end-of-day operation. Required for every store. Not a bolt-on
CRM, customer management, customer bikes, and service context CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle retail and workshop continuity. Required for bike-shop differentiation. Not a bolt-on
Customer communication basics and account-visible communication history CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required at basic level for workshop and customer follow-up. Required for customer-service maturity. Not a bolt-on
Deployment, diagnostics, support packs, backups, integrity CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required before a real shop trial. Required before any external pilot. Not a bolt-on
Financial reporting, store analysis, BI, and management dashboards CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for daily shop management and confidence. Required for every store; advanced analytics can become add-on scope later. Not a bolt-on
Inventory, stock movements, stocktake, transfers, replenishment CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle stock confidence. Required for every store. Not a bolt-on
POS, till, in-store payments, receipts, quotations, layaways CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for Clapham Cycle soft go-live. Required for every store. Not a bolt-on
Procurement, purchase orders, receiving, supplier returns CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required for core stock replenishment and supplier workflow. Required for every bike shop. Not a bolt-on
Refunds, exchanges, gift cards, liabilities, and stored value CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for controlled shop operation, especially liability review. Required for wider rollout trust. Not a bolt-on
Roles, permissions, login, PIN auth, sensitive-action controls CORE_FUNDAMENTAL_NEEDS_HARDENING Foundation Exists Required for safe staff operation. Required for rollout and support. Not a bolt-on
Rota, staff scheduling, closed days, working hours CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required where booking capacity depends on working patterns. Required for rollout; advanced HR/payroll remains out of scope. Not a bolt-on
Staff performance reporting CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Useful for launch visibility and manager coaching; attribution review, drilldowns, product classification, and cost-snapshot foundations now exist, but formal pay/incentive decisions still need policy sign-off. Commercial management feature with bike-shop-specific retail, workshop, line attribution, review workflow, scorecards, and add-on reporting now maturing. Not a bolt-on
Store Info, opening hours, public business presence, basic Google Business Profile foundation CORE_FUNDAMENTAL_NEEDS_HARDENING Foundation Exists Core public-presence foundation; advanced review/marketing automation is not launch scope. Commercially important local-presence trust layer. Not a bolt-on
Supplier integration foundation and Madison baseline path CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Core as a capability, but live automation is not required for day-one use. Commercial differentiator and paid-connector foundation. Additional supplier connectors can become paid add-ons.
System configuration, first-run onboarding, dashboard settings CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required to make the trial reproducible. Required for external onboarding later. Not a bolt-on
Workshop diary, scheduler, capacity, and online workshop booking CORE_FUNDAMENTAL_NEEDS_HARDENING Active Hardening Required as a core workshop scheduling capability; embed packaging is not launch-blocking. Required for commercial trust and customer-facing maturity. Not a bolt-on
Workshop jobs, estimates, approvals, parts, collection, print CORE_FUNDAMENTAL_NEEDS_HARDENING Built, Needs Hardening Required for Clapham Cycle. Required for every bike-shop rollout. Not a bolt-on
Release verification, merge readiness, PR process, dashboard publishing CORE_FUNDAMENTAL Trial Ready Required for release safety, though not a shop-floor feature. Required for maintainable product operations. Not a bolt-on
Staff records and staff directory CORE_FUNDAMENTAL Foundation Exists Required for staff access and operational records. Required for every store. Not a bolt-on
HQ, multi-location, location governance COMMERCIAL_HARDENING Foundation Exists Not required for single-store Clapham Cycle go-live beyond safe defaults. Important for later multi-store rollout. Not a bolt-on
Persistent customer account, profile/preferences, workshop portal unification, rental readback COMMERCIAL_HARDENING Built, Needs Hardening Helpful for customer service, but not a blocker for core in-shop operation. Important for wider customer-facing product maturity. Not a bolt-on
Stripe online payments, public payment status, refunds, reconciliation COMMERCIAL_HARDENING Active Hardening Supporting for Clapham Cycle; not required for a POS-only soft launch unless Thomas chooses online payments for day one. Required for commercial online/payment trust. Not a bolt-on
Customer-facing storefront, website checkout, online orders BOLT_ON Foundation Exists Not required for Clapham Cycle core go-live. Important later commercial/customer-facing product area. Bolt-on / commerce package candidate.
HR personnel foundation and future payroll BOLT_ON Foundation Exists Outside Clapham Cycle core go-live. Optional HR bolt-on foundation now includes personnel files, review queue, candidate offers, lifecycle event snapshots, regenerated-link controls, withdrawal evidence, and new-starter capture; payroll remains future specialist work. Paid add-on candidate.
Quote Approval public widget BOLT_ON Foundation Exists Widget packaging is not counted toward Clapham Cycle core until Thomas explicitly adds it. Merged customer-facing widget maturity for wider rollout. Bolt-on / paid add-on candidate.
Rental / hire internal platform for bikes and bike boxes BOLT_ON Built, Needs Hardening Explicitly not required for Clapham Cycle core go-live unless Thomas adds it to launch scope. Bike-shop differentiator and bolt-on candidate. Bolt-on / paid add-on candidate.
Rental / hire public request, status, widget flow, account and secure-link readback BOLT_ON Foundation Exists Not required for Clapham Cycle core go-live. Useful customer-facing bolt-on. Bolt-on / paid add-on candidate.
Rental / hire staff booking amendments BOLT_ON Foundation Exists Not counted for Clapham Cycle core readiness because rental is bolt-on scope. Merged bolt-on hardening for rental operations. Bolt-on / paid add-on candidate.
Website builder, richer public widgets, template publishing BOLT_ON Foundation Exists Commercial Web Builder packaging remains outside generic Clapham core scoring; the Clapham-specific generated website replacement is tracked separately as go-live scope. Commercial add-on / packaging area. Bolt-on / paid add-on candidate.
Additional supplier connectors beyond Madison baseline PAID_ADD_ON Planning Outside Clapham Cycle core go-live. Paid supplier connector expansion after Madison/general sync foundations are proven. Paid add-on candidate.
Advanced analytics beyond core financial/store analysis PAID_ADD_ON Foundation Exists Outside Clapham Cycle core go-live beyond basic reports. Potential premium analytics add-on. Paid add-on candidate.
Advanced Google Reviews, review requests, marketing automation, Maps/Places depth PAID_ADD_ON Planning Outside Clapham Cycle core go-live. Potential paid local-marketing add-on after public presence foundation is stable. Paid add-on candidate.
Phone system / telephony integration PAID_ADD_ON Foundation Exists Outside Clapham Cycle core go-live. Optional paid add-on candidate. Paid add-on candidate.
QuickBooks integration, mapping, posting, reconciliation controls PAID_ADD_ON Active Hardening Not required for Clapham Cycle core go-live unless Thomas explicitly adds it to day-one scope. Important paid add-on / accounting trust feature. Paid add-on candidate.
External single-store pilot after Clapham stability NOT_STARTED Planning Must not precede 3-6 months stable Clapham Cycle operation. Next rollout stage after Clapham Cycle proves stable. Not a bolt-on
Promotions, vouchers, loyalty, advanced discounting FUTURE_IDEA_OUT_OF_CURRENT_SCOPE Planning Outside Clapham Cycle core go-live unless Thomas explicitly adds it. Future retail growth idea. Future add-on possibility.
Top gaps

Most important unfinished work

  • Workshop UX and behaviour audit: A single workshop readiness audit is not yet codified, so UX debt is spread across several surfaces. high
  • Procurement and receiving maturity: Supplier API ordering, supplier returns/RMA, supplier documents, and procurement accountability still need more operational polish. high
  • Supplier / Madison integration: Live sync, supplier API ordering, and normalization maturity are still intentionally incomplete. high
  • Permissions and sensitive action hardening: Sensitive action review is still distributed across many modules rather than a single hardening ledger. high
  • Diagnostics, support packs, and operational readiness: Support-safe troubleshooting flows still need tighter packaging for real trial use. high
  • Track My Bike / Workshop Progress View: Portal polish, customer wording, and broader regression coverage still need hardening before it feels fully trial-safe. high
  • Communication Centre: email, SMS, WhatsApp: Channel reliability, support tooling, and operator trust signals still need more maturity than the raw transport foundation. high
  • Customer account / portal: Confirmed rental booking readback and storefront order-history readback are account-only and view-only; rental self-service, public confirmation, secure readback tokens, customer-visible receipt/invoice controls, and broader longitudinal account history remain future work. high
Newest ideas

Fresh thinking worth keeping

  • Communication Centre: email, SMS, WhatsApp: Track communication maturity by channel trust, orchestration depth, and customer self-service coverage.
  • Customer account / portal: Split portal maturity into identity, self-service, and ongoing customer relationship stages.
  • Customer bike lifecycle CRM: Create a bike-lifecycle maturity band that combines reminders, history, portal access, and workshop continuity.
  • Customer-facing storefront: Track storefront maturity by browse/catalogue, checkout, fulfilment, and post-purchase support.
  • Deployment / Windows / Caddy / production serving: Treat deployment readiness as its own recurring review lane rather than burying it inside docs.
  • Diagnostics, support packs, and operational readiness: Track support-bundle completeness as a first-class maturity signal beside implementation.
  • Google Business Profile / Reviews / Maps: Add a dedicated Google presence maturity lane only after controlled posting has operational evidence or public local-marketing value becomes real.
  • HR personnel foundation add-on: Keep Problem Cycle-specific bonus calculation separate from the reusable commercial HR module unless a configurable framework is deliberately commissioned.
Recommended next tasks

Immediate follow-through

  • Workshop UX and behaviour audit: Define a workshop hardening checklist covering queue, job detail, check-in, bookings, collection, and portal handoff. high
  • Workshop UX and behaviour audit: Add a compact workshop regression bundle for the highest-risk operator flows. high
  • Procurement and receiving maturity: Turn the procurement gap audit into a living maturity checklist with explicit completion criteria. high
  • Procurement and receiving maturity: Add targeted regression coverage for discrepancy and exception-resolution paths. high
  • Supplier / Madison integration: Run supervised Madison/procurement pilot sessions and use readiness decisions, the operating dashboard, and bounded evidence reports to decide whether narrow manager-led limited use remains justified. high
  • Permissions and sensitive action hardening: Map the highest-risk manager/admin actions into an explicit permissions hardening checklist. high
  • Diagnostics, support packs, and operational readiness: Keep the dashboard’s trial-readiness section concise as diagnostics, integrity, and support-pack maturity continue to grow. high
  • Track My Bike / Workshop Progress View: Add a focused portal hardening checklist covering progress wording, approvals, attachments, and reply flows. high
  • Communication Centre: email, SMS, WhatsApp: Translate post-service follow-up consent, suppression, review-request wording, Google separation, and approval policy into explicit product-data requirements before any outbound workflow is considered. high
  • Communication Centre: email, SMS, WhatsApp: Clarify the maturity ladder for workshop notifications versus broader omnichannel communication. high
Find features fast

Filter the feature map

27 features visible
Evidence warnings (1)
  • Missing evidence file for rental-bike-box-hire-internal-platform: prisma/migrations/20260613120000_rental_hire_pilot_readiness_closeout/migration.sql
Operational / Staff Workflow 72% average maturity across 8 features.
71% trial 8 features
Supplier / Madison integration The repo has real supplier-integration groundwork through reviewed Madison draft PO creation, supplier-generated draft review hardening, manual supplier submission recording, merged manager issue intake/resolution, pilot-session tracking, readiness decision records, a limited-use operating dashboard, and bounded evidence reports for management review. Current closeout says this is supervised-testing ready and conditionally suitable for narrow manager-led limited operational use, but it is intentionally conservative and not yet a live sync or supplier API ordering system.
High Active Hardening 80%

Target: operational, commercial

Last reviewed: 2026-05-15. Source: Repo audit against supplier integration routes, services, docs, closeout, and smoke coverage.

Feature maturity 80%
Evidence links (19)
Remaining gaps (2)
  • Live sync, supplier API ordering, and normalization maturity are still intentionally incomplete. high
  • Operational confidence now has pilot telemetry, readiness decisions, an operating dashboard, and evidence reports, but readiness still depends on repeated supervised trial evidence before any automation discussion. medium
Recommended next tasks (2)
  • Run supervised Madison/procurement pilot sessions and use readiness decisions, the operating dashboard, and bounded evidence reports to decide whether narrow manager-led limited use remains justified. high
  • Use operating dashboard findings to prioritize unresolved Madison questions, stale preview/link evidence, and receiving discrepancy follow-up. medium
Ideas and dependencies

Ideas

  • Track supplier integration maturity separately for preview tooling, approval tooling, and live automation.

Dependencies

  • Procurement and receiving maturity
  • Permissions hardening
Procurement and receiving maturity Purchasing and receiving are implemented enough to use, reviewed Madison suggestions can create draft POs, supplier-generated drafts now have review hardening, reviewed drafts can be manually preflighted/exported/recorded, confirmed receipt discrepancies now have internal manager resolution history, and managers now have merged supplier integration issue resolution, pilot-session tracking, readiness decisions, and a limited-use operating dashboard with evidence, blockers, confidence, next review, and recent activity; supplier API ordering and procurement exception maturity remain hardening work.
High Active Hardening 79%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit plus procurement readiness and limited-use closeout docs already committed on main.

Feature maturity 79%
Evidence links (11)
Remaining gaps (2)
  • Supplier API ordering, supplier returns/RMA, supplier documents, and procurement accountability still need more operational polish. high
  • Manager trust signals now have merged pilot sessions, issue queues, readiness decisions, and a limited-use operating dashboard, but broader procurement exception resolution remains split across specialist workflows. medium
Recommended next tasks (2)
  • Turn the procurement gap audit into a living maturity checklist with explicit completion criteria. high
  • Add targeted regression coverage for discrepancy and exception-resolution paths. high
Ideas and dependencies

Ideas

  • Show procurement maturity as its own dashboard slice with explicit remaining exception classes.
  • Use the supplier operating dashboard evidence as an input to future procurement exception reporting.

Dependencies

  • Supplier / Madison integration
  • Diagnostics and operational readiness
POS / till / retail workflow Retail checkout is a strong foundation and one of the most operationally credible areas in the repo.
High Active Hardening 76%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against POS routes, pages, and smoke coverage.

Feature maturity 76%
Evidence links (4)
Remaining gaps (2)
  • Trial-facing runbooks and operator guidance are thinner than the implementation depth. medium
  • Broader end-to-end coverage for mixed tender and exception cases can still improve confidence. medium
Recommended next tasks (2)
  • Expand retail regression coverage around mixed tenders, refunds, receipts, and edge-case operator states. medium
  • Add a POS/trade-close readiness checklist to the support docs set. medium
Ideas and dependencies

Ideas

  • Track recurring POS trial friction separately from feature completion so operator confidence has its own signal.

Dependencies

  • Permissions hardening
  • Diagnostics and support readiness
Deployment / Windows / Caddy / production serving Deployment guidance and production frontend serving exist, but this is still operationally sensitive enough to keep under active hardening.
High Active Hardening 72%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against deployment docs and serving verification scripts.

Feature maturity 72%
Evidence links (4)
Remaining gaps (2)
  • Deployment confidence still depends on disciplined manual process rather than a single hardened release dashboard. medium
  • Windows/Caddy/operator troubleshooting maturity is documented but not yet deeply operationalized in the new dashboard layer. medium
Recommended next tasks (2)
  • Expose deployment readiness warnings and evidence paths directly in the dashboard output. medium
  • Add a concise trial-store release checklist pointer from the dashboard summary. medium
Ideas and dependencies

Ideas

  • Treat deployment readiness as its own recurring review lane rather than burying it inside docs.

Dependencies

  • Managed printing / print agent
  • Verification / multi-agent tooling
Diagnostics, support packs, and operational readiness Diagnostics, integrity, and support assets are strong enough to count as implemented, but still need better operational packaging.
High Built, Needs Hardening 72%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against diagnostics pages, support docs, and smoke coverage.

Feature maturity 72%
Evidence links (4)
Remaining gaps (2)
  • Support-safe troubleshooting flows still need tighter packaging for real trial use. high
  • The new compact dashboard is more shareable, but support-safe review habits and trend history are still not routine enough yet. medium
Recommended next tasks (2)
  • Keep the dashboard’s trial-readiness section concise as diagnostics, integrity, and support-pack maturity continue to grow. high
  • Add a documented checklist for what should be reviewed before asking a trial shop to self-diagnose. medium
Ideas and dependencies

Ideas

  • Track support-bundle completeness as a first-class maturity signal beside implementation.

Dependencies

  • Deployment / production serving
  • Verification / multi-agent tooling
Stocktake and inventory accuracy Stocktake is clearly implemented and should be tracked as a hardening problem, not a missing feature.
High Built, Needs Hardening 70%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against stocktake pages, routes, services, and smoke tests.

Feature maturity 70%
Evidence links (4)
Remaining gaps (2)
  • Stocktake UX still needs a cleaner operator narrative for review, finalize, and exception handling. medium
  • Inventory accuracy diagnostics are present, but stocktake-specific readiness reporting is still thin. medium
Recommended next tasks (2)
  • Add stocktake operational guidance to the support docs with review/finalize troubleshooting. medium
  • Track variance-resolution quality separately from the raw ability to run a stocktake session. medium
Ideas and dependencies

Ideas

  • Surface stocktake confidence trends and repeat variance hotspots on the dashboard layer.

Dependencies

  • Diagnostics and support-pack readiness
  • Procurement and receiving maturity
Workshop UX and behaviour audit Workshop operations are broad and visibly implemented, but workflow friction and coverage still need deliberate hardening before trial use feels calm.
High Built, Needs Hardening 66%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against current workshop pages, services, and E2E coverage.

Feature maturity 66%
Evidence links (4)
Remaining gaps (2)
  • A single workshop readiness audit is not yet codified, so UX debt is spread across several surfaces. high
  • Automation depth is still lighter than the breadth of the workshop UI surface. medium
Recommended next tasks (2)
  • Define a workshop hardening checklist covering queue, job detail, check-in, bookings, collection, and portal handoff. high
  • Add a compact workshop regression bundle for the highest-risk operator flows. high
Ideas and dependencies

Ideas

  • Add a release-facing workshop scorecard that tracks friction hotspots by sub-flow.

Dependencies

  • Diagnostics and support-pack maturity
  • Customer portal hardening
Permissions and sensitive action hardening Role-aware infrastructure is broad, but repo-owned tracking should keep calling out the difference between route guards and true operational safety.
High Foundation Exists 61%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against auth middleware, routes, UI, and smoke coverage.

Feature maturity 61%
Evidence links (4)
Remaining gaps (2)
  • Sensitive action review is still distributed across many modules rather than a single hardening ledger. high
  • Staff-facing wording and escalation guidance for denied/guarded actions can still be improved. medium
Recommended next tasks (2)
  • Map the highest-risk manager/admin actions into an explicit permissions hardening checklist. high
  • Add support-doc guidance for common permission failures and safe escalation. medium
Ideas and dependencies

Ideas

  • Track sensitive action maturity separately from login/auth maturity so hardening work is visible.

Dependencies

  • Diagnostics and operational readiness
  • Support agent / help system
Customer Facing 75% average maturity across 8 features.
66% trial 8 features
Web builder / templates / embeddable widgets This should be treated as partial only. Public site, Store Info wiring, styling settings, the workshop booking iframe, the Track My Bike secure-link iframe, the Quote Approval secure-link iframe, a read-only Store Info/opening-hours iframe, a request-first rental/hire iframe, a central Public Widgets hub, the Web Builder V1 data/admin shell, the Workshop-first template, the Retail + workshop template, the Premium service template, the first public catalogue contract, guarded generated-site purchasable product browsing, anonymous storefront basket intent, public preview/share links, and bounded template image blocks now exist. The shell has AppConfig-backed setup state, Store Info dependency visibility, widget reuse guidance, manager/admin preview routes, public-safe stakeholder share links, manager-controlled dedicated-route public publishing for available templates, a first-run checklist, support-safe generated-site diagnostics, constrained theme controls, and image-block controls for template-defined slots. Template 1 now has first content, section, SEO, metadata, accessibility, mobile/performance, support/onboarding, purchasable product cards, search/category filters, basket-token checkout handoff, compatibility SKU/quantity checkout fallback, and bounded imagery passes. Public checkout can carry generated-site basket-token or SKU/quantity intent while collecting customer contact and shipping details for server-side checkout validation. Task 35A now implements optional signed-in storefront checkout and basket checkout account attachment plus view-only account-owned web-order history, while preserving guest checkout and rejecting guest-order inference by email, phone, name, postcode, basket token, or order text. Task 36 now enriches paid storefront order payment-received emails with customer-safe receipt/invoice details, staff-visible send state, and explicit manager resend without changing payment/accounting truth. Task 37 records an EasyPost/aggregator-first courier decision while keeping direct Royal Mail, DPD, DHL, and other branded adapters behind pilot evidence gates. Task 38 adds server-owned UK shipping-rate/address validation and trusted shipping charges. Task 39 adds customer-safe collection/dispatch notifications from authoritative fulfilment/provider state with staff-visible send/review/failure state and no payment/accounting mutation. Task 41 is runtime-complete for explicit storefront product/variant publishing controls: active products stay hidden by default, `/online-store/products` is the manager-owned public product control surface, the public catalogue contract includes `publicationAuthority`, browse-only products avoid checkout handoff, category/featured/sort ordering stays server-owned, and basket/direct checkout revalidates against publishing state. Task 42 is runtime-complete for bounded storefront product media: manager-owned upload/external-URL controls validate PNG/JPEG/WebP media, public catalogue v3 exposes only approved public-safe `primaryImage` data with alt text, and generated product cards render fixed-aspect image or text fallback states. Task 43 is runtime-complete for storefront merchandising diagnostics and launch readiness: Web Builder now reports public product availability, category readiness, featured-product exposure/suppression, product-media/fallback state, browse-only/checkout state, and Clapham pilot launch blockers without changing public catalogue or checkout authority. Template 2 now has a publishable retail/workshop body with product browsing, basket intent, and widget reuse on the same dedicated route and readiness gates. Template 3 now has a publishable premium-service body and uses the same manager-controlled readiness gates on the dedicated route. The repo now has a Web Builder delivery plan, task queue, product browsing integration audit, storefront merchandising/product-media/publish-controls plan, customer-account checkout/order-history contract, storefront courier-adapter decision audit, Clapham migration evidence records, Clapham route-inventory/decision-matrix evidence, Clapham route-map candidate/approval-packet/remaining-blocker evidence, Clapham migration verification/support planning, and a commercial/pilot readiness audit. Thomas approved Task 29 repo implementation on 2026-05-16, moving the Clapham generated-site replacement out of blocked planning and toward implementation/pilot readiness; DNS/custom-domain/production launch evidence remains pending. The commercial audit keeps the Clapham Cycle replacement as the proof case, Public Widgets as the widget-only option for stores with existing websites, and broader Web Builder packaging as a future commercial bolt-on. A general CMS/page builder, unrestricted media library, supplier media auto-import, billing/entitlement system, custom-domain automation, and generic external-store pilot process do not exist yet.
Medium Foundation Exists 93%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against public-site pages, Store Info wiring, Web Builder Template 1, and styling settings.

Feature maturity 93%
Evidence links (111)
Remaining gaps (5)
  • The three initial templates are publishable on the dedicated generated-site route with constrained theme presets, public preview/share links, and bounded image blocks; multi-page generated sites, unrestricted media management, advanced per-template theming, and a general CMS/page builder remain future work. high
  • Clapham Cycle generated-site replacement is now approved for Task 29 repo implementation and has evidence-capture, route-map candidate, approval packet, verification, support planning, route-ownership smoke, source-evidence consistency, and live-route recrawl records, but live DNS/custom-domain/production launch evidence, policy/external-route/high-value legacy redirect decisions, existing-site widget trial rehearsal, rollback rehearsal, deployment ownership, and manager/admin launch sign-off remain unfinished. high
  • The commercial/pilot audit defines package boundaries, but billing, entitlement checks, custom-domain provisioning, generic future-store onboarding, support SLA/owner model, and an external pilot process are not implemented. high
  • Task 43 now provides storefront merchandising diagnostics, but exact stock quantities, direct carrier adapters, product/package-specific parcel rules, delivery promises, unrestricted CMS media, and deeper storefront behavior remain future work. medium
  • Workshop booking, Track My Bike, Quote Approval, Store Info, and rental request iframes are live, but script-loader embeds, auto-resize, and per-origin allowlist UI remain future work. medium
Recommended next tasks (7)
  • Fill or accept the generated-site review, existing-site widget-trial, risk/rollback, deployment-owner, support-owner, production-serving, and remaining launch evidence records before DNS/custom-domain/production launch. high
  • Use the commercial/pilot readiness audit to design a generic future-store onboarding packet, support runbook, entitlement/pricing boundary, custom-domain launch process, and external pilot entry/exit matrix before scheduling a non-Clapham store. high
  • Resolve remaining policy-page, external club/bike-fit, high-value legacy redirect, deployment, and rollback ownership decisions before live launch. high
  • Review generated-site image choices, alt/decorative wording, aspect fit, external image hosts, and mobile layout before live launch. high
  • Reuse the public catalogue and basket-token contracts in future templates only with purchasable-only filtering, server-side estimates, and server-side price/stock authority intact. medium
  • Do not start Task 44 Clapham production launch rehearsal/sign-off until real Clapham review, widget trial, deployment, rollback, production-serving, support-owner, and final manager/admin evidence is available. high
  • Use docs/web_builder_task_queue.md as the source of sequencing truth for generated-site image review, diagnostics, and public-site migration work. medium
Ideas and dependencies

Ideas

  • Track website maturity as layers: Store Info wiring, templates, content blocks, widget composition, and publish workflow.

Dependencies

  • Customer account / portal
  • Online workshop booking
  • Customer-facing storefront
  • Google Business Profile / Reviews / Maps
Customer account / portal The first customer account + workshop portal unification milestone is implemented, with the dashboard now prioritising customer next actions before the supporting account sections. The account is the customer workshop home while quote/progress and booking-manage token flows remain valid deep links, saved bikes can open a focused customer-safe profile/history/detail view with service reminder readiness, customers can manage a conservative phone/contact-channel preference foundation without changing identity or staff CRM data, Messages & updates gives read-only visibility into safe workshop communications, authenticated account rental booking visibility now shows customer-safe staff-confirmed hire summaries, and manager-side post-service follow-up readiness/decisions/preview-copy history/outcomes can respect contact permissions without customer-facing automation.
High Built, Needs Hardening 80%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against customer account pages, routes, and smoke coverage.

Feature maturity 80%
Evidence links (17)
Remaining gaps (3)
  • Confirmed rental booking readback and storefront order-history readback are account-only and view-only; rental self-service, public confirmation, secure readback tokens, customer-visible receipt/invoice controls, and broader longitudinal account history remain future work. high
  • Richer service reminder/review-request consent, verified email-change, customer reply behavior from the account, outbound reminder sending, and outbound follow-up/review-request workflows are still future customer-account work despite the staff-only preview and outcome aids. high
  • Customer-facing rollout guidance, support docs, and trust/diagnostics signals still need commercial hardening. medium
Recommended next tasks (3)
  • Harden customer-account profile/privacy review coverage before expanding identity, consent, reminder-sending, or message payloads. high
  • Keep customer account order history view-only while customer-visible receipt/invoice controls and post-purchase storefront support mature. high
  • Decide how far customer-account bike profiles should go into attachments and maintenance recommendations before expanding broader account history. medium
Ideas and dependencies

Ideas

  • Split portal maturity into identity, self-service, and ongoing customer relationship stages.

Dependencies

  • Track My Bike / Workshop Progress View
  • Online workshop booking
Track My Bike / Workshop Progress View This is not missing. The repo already has a secure workshop portal with progress, quote approval, conversation, attachments, timeline, account-dashboard deep links, an iframe Track My Bike widget foundation, and an iframe Quote Approval widget foundation that open existing secure links without public lookup.
High Built, Needs Hardening 77%

Target: customer-facing, trial

Last reviewed: 2026-05-15. Source: Repo audit against public workshop routes, portal UI, and workshop conversation/attachment services.

Feature maturity 77%
Evidence links (11)
Remaining gaps (2)
  • Portal polish, customer wording, and broader regression coverage still need hardening before it feels fully trial-safe. high
  • The first iframe widgets are secure-link helpers only; they do not show compact validated progress or quote summaries inside the iframe. medium
Recommended next tasks (2)
  • Add a focused portal hardening checklist covering progress wording, approvals, attachments, and reply flows. high
  • Decide whether later progress or quote widgets should add server-validated token handoff/rendered summaries or stay as link-out helpers while the secure portal remains the decision engine. medium
Ideas and dependencies

Ideas

  • Track portal maturity separately from workshop internal maturity so customer-facing readiness is visible.

Dependencies

  • Communication Centre
  • Workshop service history and customer portal
Online workshop booking Public workshop booking now has a server-side capacity contract, staff diagnostics, a hardened iframe-safe widget route, and a central Public Widgets manager hub for readiness, snippets, preview, and live companion widget slots.
Medium Active Hardening 76%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against public booking pages, routes, and roadmap guidance.

Feature maturity 76%
Evidence links (13)
Remaining gaps (2)
  • The first widget is still iframe-only; there is no host-page script loader, auto-resize bridge, per-origin admin allowlist UI, or advanced theme configuration yet. medium
  • Staff override policy, service-category duration tuning, and confirmation wording still need more operational polish before broad public rollout. medium
Recommended next tasks (2)
  • Use trial feedback from the Public Widgets hub to decide whether iframe auto-resize, script-loader support, per-origin allowlist UI, or richer widget theming should come next. medium
  • Add staff override/confirmation guidance for exceptions that customers cannot self-book online. medium
Ideas and dependencies

Ideas

  • Track online booking maturity separately from the web-builder/widget layer to avoid over-crediting the website shell.

Dependencies

  • Web builder / templates / embeddable widgets
  • Workshop UX and behaviour audit
Communication Centre: email, SMS, WhatsApp This is also not missing. Notification orchestration and channel services already exist, customers now have a read-only account view of safe workshop messages and delivered notification copies, and managers have a no-send post-service follow-up loop with readiness, internal review decisions, durable preview/copy history, manual preview assistance, manual outcome logging, operational ageing/reporting, fixed ageing-policy guidance, consent/suppression/review-request governance policy, gap filters, and dashboard attention surfacing for completed workshop jobs; the remaining work is product-data design, trust, rollout, and outbound policy implementation discipline.
High Built, Needs Hardening 73%

Target: customer-facing, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against notification orchestration, delivery services, and customer communication UI.

Feature maturity 73%
Evidence links (13)
Remaining gaps (2)
  • Channel reliability, support tooling, and operator trust signals still need more maturity than the raw transport foundation. high
  • Direct messaging, delivery-state explanations, customer reply behavior, dedicated consent/suppression product data, and outbound follow-up/review-request implementation remain future work beyond the no-send decision, preview/copy, outcome-logging, ageing-policy, and governance-policy foundation. medium
Recommended next tasks (3)
  • Translate post-service follow-up consent, suppression, review-request wording, Google separation, and approval policy into explicit product-data requirements before any outbound workflow is considered. high
  • Clarify the maturity ladder for workshop notifications versus broader omnichannel communication. high
  • Add support-facing delivery diagnostics and operator guidance to the dashboard links and docs. medium
Ideas and dependencies

Ideas

  • Track communication maturity by channel trust, orchestration depth, and customer self-service coverage.

Dependencies

  • Track My Bike / Workshop Progress View
  • Customer account / portal
Customer-facing storefront Website checkout, online-store foundations, the first public catalogue contract, a guarded generated-site purchasable product browsing consumer, the Task 34 anonymous storefront basket foundation, the Task 35A customer-account checkout/order-history runtime foundation, the Task 36 storefront receipt/invoice email foundation, the Task 37 EasyPost/aggregator-first courier decision audit, the Task 38 shipping-rate/address-validation runtime foundation, the Task 39 collection/dispatch notification foundation, the Task 40 storefront merchandising/product-media/publish-controls plan, the Task 41 storefront product publishing runtime foundation, the Task 42 product media runtime foundation, and the Task 43 merchandising diagnostics/launch-readiness foundation now exist. Product browsing exposes customer-safe product identity, explicit product/variant publishing state, publicationAuthority, browse-only public product states without checkout handoff, purchasable-only filtering, search/category filters, basket-token checkout handoff, compatibility SKU checkout fallback, base retail price display, coarse availability, fulfilment wording, approved public-safe primary images, fixed-aspect fallback cards, and server-owned category/featured/sort ordering. Basket preview stores SKU/quantity intent only, recalculates customer-safe estimates server-side, blocks unavailable lines and coarse over-limit quantities, handles concurrent same-SKU adds, guards line mutations against checkout races, atomically claims checkout before creating the public website checkout, and revalidates basket lines against current publishing state. Checkout can be retried against the same basket token when a successful response is lost. Checkout can capture contact and shipping details while still sending SKU/quantity intent for server-side validation, and direct SKU checkout revalidates against current publishing state before order creation. Shipping checkout now requests server-owned UK shipping options, requires a selected validated option before Stripe opens, revalidates that option server-side, persists the selected provider/service/address-validation snapshot on WebOrder, and includes the trusted shipping charge in WebOrder/Stripe totals. Collection/dispatch notifications now cover ready-for-collection, collected, dispatched, tracking-available, delivery-exception, and cancellation/refund fulfilment states using authoritative CorePOS fulfilment/provider state, idempotent sends, and staff-visible skipped/failed/review-required outcomes. Signed-in direct storefront checkout and basket checkout can attach new WebOrders by authenticated customer session only. Customer account order history is scoped by WebOrder.customerId, not email, phone, name, postcode, basket token, or order-text matching, and stays view-only without payment/refund/shipment/stock/accounting mutation. Paid storefront orders enrich the existing idempotent Stripe payment-received email with customer-safe receipt/invoice body content and manager-visible resend/failure review without adding payment/accounting mutation. Web Builder diagnostics now explain public product availability, category readiness, featured-product exposure or suppression, product media fallback/review state, browse-only versus checkout-ready state, and Clapham launch blockers without changing public catalogue, media, basket, checkout, payment, fulfilment, or route authority. This is still not a finished storefront product because direct carrier adapters, product/package-specific parcel rules, exact stock quantities, exact delivery promises, DNS/custom-domain launch, and broader post-purchase support remain separate milestones.
Medium Foundation Exists 71%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against website checkout, online-store routes, and smoke coverage.

Feature maturity 71%
Evidence links (75)
Remaining gaps (2)
  • Task 43 now provides merchandising diagnostics and launch-readiness visibility, but exact stock quantities, direct carrier adapters, product/package-specific parcel rules, delivery promises, DNS/custom-domain launch, and broader e-commerce trust remain future work. high
  • Storefront maturity should not be conflated with narrow checkout/payment groundwork. high
Recommended next tasks (5)
  • Keep generated-site product browsing reuse constrained to the public catalogue contract, purchasable-only filtering, basket-token checkout handoff, and server-side estimates. medium
  • Pilot the shipping-rate/address foundation with real Store Info origin readiness and EasyPost sandbox credentials before promising live courier services. high
  • Do not start Clapham production launch rehearsal/sign-off until real generated-site review, widget trial, production-serving, deployment-owner, support-owner, rollback, and manager/admin evidence is available. high
  • Sequence product/package parcel rules, direct carrier adapters, exact delivery promises, and broader post-purchase support as separate follow-on milestones. high
  • Keep storefront readiness reporting separated into browse/catalogue, checkout, fulfilment, and post-purchase support layers. medium
Ideas and dependencies

Ideas

  • Track storefront maturity by browse/catalogue, checkout, fulfilment, and post-purchase support.

Dependencies

  • Web builder / templates / embeddable widgets
  • Stripe / payment trust
Google Business Profile / Reviews / Maps Readiness, OAuth, read-only reviews, internal reply approvals, explicit approved-draft reply posting, and local operations/runbook diagnostics are real; this remains an internal Google presence foundation rather than a public/local-marketing product.
Medium Foundation Exists 63%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against readiness UI, OAuth, read-only reviews, internal reply drafts, approved-draft posting hardening, operations diagnostics tests, and Google planning docs.

Feature maturity 63%
Evidence links (14)
Remaining gaps (2)
  • Bulk/automatic reply posting, posted-reply update/delete, public review display, review requests, Maps/Places, and local-marketing automation remain intentionally unimplemented. high
  • This area should stay explicitly lower-maturity until customer-facing value is more than configuration readiness. medium
Recommended next tasks (3)
  • Run the first single-location controlled production live trial using the production-readiness audit before any broader Google feature work. high
  • Keep approved-draft posting, future posted-reply update/delete, review requests, and public display as separate tracked states. high
  • Plan any future posted-reply update/delete workflow as a separate explicit, audited, manager-approved milestone. medium
Ideas and dependencies

Ideas

  • Add a dedicated Google presence maturity lane only after controlled posting has operational evidence or public local-marketing value becomes real.

Dependencies

  • Web builder / templates / embeddable widgets
  • Store Info and public-site readiness
Rental / hire customer-facing flow The first public rental slice now exists as a request-first, customer-safe enquiry flow with staff-side quote/response handling and an embeddable iframe widget. Authenticated customer accounts and staff-generated secure readback links can now show customer-safe summaries of staff-confirmed hire bookings, but the flow remains deliberately short of self-service confirmation, reservation, amendments, cancellation, payment, upload, or digital signing.
Medium Foundation Exists 62%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against rental foundation pages, smoke coverage, and readiness docs.

Feature maturity 62%
Evidence links (24)
Remaining gaps (3)
  • Customers still cannot confirm a rental themselves, reserve an asset, accept a quote live, pay a deposit, sign a waiver, upload evidence, cancel, reschedule, or manage the booking through self-service. high
  • Customer-send automation remains future work; current secure readback links are generated and shared manually by staff. medium
  • Manual communication remains the safe default because the rental-specific outbound-message and acceptance model is still intentionally conservative. medium
Recommended next tasks (2)
  • Keep the public rental flow request-first until manual response, availability, waiver, and deposit boundaries are trusted enough for a later confirmation step. high
  • Decide whether any later customer-send automation should reuse an existing safe communications subsystem or stay manual by default. medium
Ideas and dependencies

Ideas

  • Track rental maturity as two linked streams: internal fleet operations and customer self-service.

Dependencies

  • Rental / bike box hire internal platform
  • Web builder / templates / embeddable widgets
Bike-shop-specific 76% average maturity across 4 features.
69% trial 4 features
Rental / bike box hire internal platform Internal rental operations now cover booking, pricing, readiness, intake review, customer-response handoff, staff-only evidence references, versioned hire terms, staff-witnessed waiver acknowledgement records, staff-only reschedule/extension/early-return/asset-swap amendments, staff/manager-only deposit and damage outcome reviews, staff-only maintenance request links to existing internal workshop jobs, account-only customer-safe confirmed-booking visibility, staff-generated secure readback links, and manager pilot-readiness closeout decisions, but still need upload/public signing and broader operational finishing.
Medium Built, Needs Hardening 85%

Target: operational, commercial

Last reviewed: 2026-05-15. Source: Repo audit against rental pages, services, docs, and smoke coverage.

Feature maturity 85%
Evidence links (37)
Remaining gaps (3)
  • Authenticated rental upload/download, customer-visible evidence, customer self-signing, public digital waiver signing, and public rental self-service remain intentionally unimplemented. high
  • Operational polish, customer documents, dispute follow-up, internal fleet workshop-job creation policy, and later payment/accounting strategy are still incomplete. medium
  • The internal platform is ahead of the customer-facing flow, which limits end-to-end commercial readiness. medium
Recommended next tasks (5)
  • Run a controlled staff pilot and use pilot-readiness decisions, exception queues, and the runbook to decide what remains unsafe before wider use. high
  • Track rental maturity by sub-capability: booking, amendments, pricing, agreement pack, return/condition, evidence, deposit/damage outcomes, maintenance requests, request handoff, and manual customer follow-up. high
  • Define a dedicated internal/fleet workshop-job pattern before allowing rental maintenance requests to create workshop jobs directly. medium
  • Plan rental uploads and customer self-signing as separate explicit milestones with authenticated storage, legal retention rules, and no public leakage. high
  • Add a clearer internal-vs-public maturity split in docs and reports. medium
Ideas and dependencies

Ideas

  • Expose rental sub-feature maturity on the dashboard once the base tracker is established.

Dependencies

  • Rental / hire customer-facing flow
  • Managed printing / labels / print agent
Service reminders Service reminders are implemented for staff review, customer account bike detail pages show read-only reminder readiness using safe service history, active service schedules, and contact permissions, and the manager communication queue now adds no-send post-service follow-up readiness, operations ageing, fixed ageing-policy guidance, governance policy, internal decision records, durable preview/copy events, manual draft-preview assistance, manual outcome logging, gap filters, and dashboard attention surfacing for completed jobs. Outbound reminder and follow-up delivery remain intentionally unimplemented.
Medium Built, Needs Hardening 75%

Target: operational, customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against reminders page, service, and smoke coverage.

Feature maturity 75%
Evidence links (13)
Remaining gaps (2)
  • Dedicated opt-in/out semantics, suppression product data, and outbound delivery remain future work; governance policy now exists but is not a sending implementation. medium
  • Customer-facing readiness is intentionally lightweight and does not yet provide customer-managed schedules or full service-plan editing. medium
Recommended next tasks (3)
  • Translate consent, suppression, review-request copy governance, Google separation, and approval policy into data requirements before any explicit staff-approved outbound policy is implemented. high
  • Document what makes reminder and post-service follow-up readiness trusted enough to become explicit staff-approved outbound policy. medium
  • Keep reminder and follow-up maturity tied to communication, consent, review-request separation, and customer account privacy checks before enabling any sends. medium
Ideas and dependencies

Ideas

  • Add a reminder confidence signal that captures channel readiness and follow-through quality.

Dependencies

  • Communication Centre
  • Customer bike lifecycle CRM
Customer bike lifecycle CRM Customers, bikes, bike-linked history, service schedules, customer-visible reminder readiness, manager-only post-service follow-up readiness, internal follow-up decisions, durable preview/copy history, staff-prepared manual preview assistance, manual outcome logging, follow-up operations ageing/reporting, fixed ageing-policy guidance, consent/suppression/review-request governance policy, gap filters, and dashboard attention surfacing clearly exist, but the deeper CRM operating model is still maturing.
High Built, Needs Hardening 72%

Target: operational, commercial

Last reviewed: 2026-05-15. Source: Repo audit against customer bike services, pages, and timeline coverage.

Feature maturity 72%
Evidence links (13)
Remaining gaps (2)
  • Lifecycle CRM value is present, but the repo does not yet expose a clear product-level maturity story for it. medium
  • Support and training material still emphasize individual pages more than the full customer-bike relationship workflow. medium
Recommended next tasks (3)
  • Translate consent, suppression, review-request wording, Google separation, and approval policy into product-data requirements before any outbound follow-up or review-request action is designed. high
  • Define which customer-bike lifecycle outcomes count as own-shop trial-ready versus broader commercial rollout-ready. medium
  • Define the implementation threshold for moving from recorded internal decisions to any explicit outbound follow-up or review-request action. medium
Ideas and dependencies

Ideas

  • Create a bike-lifecycle maturity band that combines reminders, history, portal access, and workshop continuity.

Dependencies

  • Service reminders
  • Workshop service history and customer portal
Workshop service history and customer portal The account dashboard exposes a safe service-history foundation directly under saved customer bikes, and saved bikes now open a focused customer-safe profile/history detail view with conservative service reminder readiness. Unassigned completed visits stay separate and a fuller bike-maintenance record remains future work.
Medium Built, Needs Hardening 71%

Target: customer-facing, commercial

Last reviewed: 2026-05-15. Source: Repo audit against customer account and workshop portal surfaces.

Feature maturity 71%
Evidence links (5)
Remaining gaps (2)
  • Service history is still conservative and summary oriented rather than a full longitudinal bike maintenance record with attachments, customer-managed schedules, and outbound reminder policy. medium
  • Broader commercial rollout self-service history and customer continuity still need a stronger product definition. medium
Recommended next tasks (2)
  • Define the next customer-bike maintenance timeline scope beyond reminder readiness for a trial-ready customer portal. medium
  • Decide which workshop notes, attachments, and final summaries should become durable customer history versus live-job portal detail. medium
Ideas and dependencies

Ideas

  • Promote service history into a cross-cutting customer relationship feature rather than only a workshop portal extension.

Dependencies

  • Track My Bike / Workshop Progress View
  • Customer account / portal
Platform / Commercial 66% average maturity across 7 features.
62% trial 7 features
Verification / multi-agent tooling The repo has strong multi-worktree verification tooling, explicit merge-readiness guardrails, a merged canonical Codex submit wrapper, and a merged fast-gate watcher; this is one of the most mature internal platform areas.
High Trial Ready 84%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against verification wrappers, tests, and docs.

Feature maturity 84%
Evidence links (7)
Remaining gaps (2)
  • The verification model is strong internally, but the new submit/watch flow still needs repeated multi-agent usage and future trend-history depth before this area feels fully mature. medium
  • Trial-ready here does not mean zero maintenance; it still needs careful visibility as repo processes evolve. low
Recommended next tasks (3)
  • Track whether the merged submit/watch flow reduces stale-branch conflict and rerun churn across the next multi-agent batch. medium
  • Keep the single-page dashboard aligned with verification workflow changes so maturity stays visible without manual repo spelunking. medium
  • Keep test coverage close to any future workflow changes so maturity stays earned. medium
Ideas and dependencies

Ideas

  • Surface verification maturity and repo-process trust as a reusable internal KPI.

Dependencies

  • Diagnostics and support-pack readiness
  • Deployment / production serving
Stripe/payment trust Stripe foundations are deep and clearly implemented. Storefront payment-received email now carries customer-safe receipt/invoice summary content for paid web orders and supports explicit manager resend/failure review without changing payment/accounting truth, but operational trust is still a separate maturity step.
High Active Hardening 76%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against Stripe routes, public status UI, docs, and extensive test coverage.

Feature maturity 76%
Evidence links (6)
Remaining gaps (2)
  • Production trust still depends on conservative rollout, observability, and support clarity rather than feature absence. high
  • Customer-facing checkout and refund experiences should stay clearly separated from internal accounting maturity. medium
Recommended next tasks (2)
  • Keep Stripe maturity split between implementation breadth and rollout trust in the dashboard summary. high
  • Add a concise list of remaining operational confidence tasks for online payments. medium
Ideas and dependencies

Ideas

  • Track payment trust by customer checkout, internal review, refund handling, and reconciliation confidence.

Dependencies

  • QuickBooks / accounting trust
  • Customer-facing storefront
QuickBooks/accounting trust QuickBooks foundations are strong, but they are intentionally conservative and still best described as trust-building hardening work.
High Active Hardening 74%

Target: operational, trial, commercial

Last reviewed: 2026-05-15. Source: Repo audit against QuickBooks pages, services, smoke tests, and support docs.

Feature maturity 74%
Evidence links (4)
Remaining gaps (2)
  • Manager trust, review UX, and production trial confidence still need careful hardening before broader rollout. high
  • Accounting maturity is broad enough that summary reporting needs to stay explicit about what is conservative by design. medium
Recommended next tasks (2)
  • Expose QuickBooks trust maturity as review-led, not just feature-count complete. high
  • Keep linking dashboard maturity to trial validation, evidence review, and stored-value reconciliation coverage. medium
Ideas and dependencies

Ideas

  • Track accounting trust as a composite of connection, mapping, dry-run, posting, validation, and exception review.

Dependencies

  • Stripe / payment trust
  • Diagnostics and operational readiness
Managed printing / labels / print agent Printing foundations are meaningful and practical, but still operationally sensitive enough to keep under hardening.
Medium Built, Needs Hardening 66%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against print-agent source, managed print routes, docs, and smoke coverage.

Feature maturity 66%
Evidence links (4)
Remaining gaps (2)
  • Printer/device support and operational troubleshooting are still more foundation-grade than fully normalized. medium
  • Printing readiness should stay linked to deployment/runtime confidence, not treated as isolated automation. medium
Recommended next tasks (2)
  • Expose print-agent evidence and remaining setup friction directly in the dashboard outputs. medium
  • Document the practical difference between print foundation and fully managed printing trust. medium
Ideas and dependencies

Ideas

  • Track printing maturity by device support, dispatch reliability, and operator recovery steps.

Dependencies

  • Deployment / Windows / Caddy / production serving
Multi-location / HQ HQ and multi-location foundations are real, but the roadmap still treats broader operational readiness as near-term future work.
Medium Foundation Exists 54%

Target: operational, commercial

Last reviewed: 2026-05-15. Source: Repo audit against HQ pages, routes, and smoke coverage.

Feature maturity 54%
Evidence links (4)
Remaining gaps (2)
  • Broader multi-store workflow depth is still limited beyond the current HQ groundwork. high
  • Single-store safe defaults are good, but multi-store operating maturity is not yet broad enough to over-credit. medium
Recommended next tasks (2)
  • Keep multi-location maturity explicitly below customer-facing and accounting scope claims until more workflows are location-safe. high
  • Add clearer evidence links for what is HQ-ready versus still single-store-first. medium
Ideas and dependencies

Ideas

  • Track multi-location maturity by governance, visibility, workflow safety, and commercial rollout depth.

Dependencies

  • Permissions and sensitive action hardening
  • Customer-facing storefront
HR personnel foundation add-on The HR bolt-on now has personnel files, a sanitized admin review queue, a candidate/offer flow, hash-only public offer acceptance links, offer lifecycle event snapshots, regenerated-link/withdrawal controls, new-starter capture, and draft employee-profile conversion. Contract signing, payroll, public evidence upload, and legal/compliance automation remain future work.
Medium Foundation Exists 47%

Target: commercial

Last reviewed: 2026-05-18. Source: Repo audit against HR plan, schema, admin API/UI, review-summary endpoint, document vault, support docs, and smoke coverage.

Feature maturity 47%
Evidence links (15)
Remaining gaps (2)
  • Contract template/signing, public identity-document upload, right-to-work evidence approval workflow, leaver/disciplinary records, payroll exports, legal pay validation, and bonus calculations are not implemented. high
  • Commercial rollout still needs HR-specific permissions, retention policy, encryption/key-management review, legal/compliance review, and operational support packaging. high
Recommended next tasks (2)
  • Run Problem Cycle trial use against real candidate, offer, and new-starter needs before adding contract signing. high
  • Design M-HR3 contract templates/signing with explicit evidence, retention, and legal-review boundaries. high
Ideas and dependencies

Ideas

  • Keep Problem Cycle-specific bonus calculation separate from the reusable commercial HR module unless a configurable framework is deliberately commissioned.

Dependencies

  • Permissions and sensitive action hardening
  • Diagnostics and support-pack readiness
  • Email delivery and public token flows
Support agent / staff help system The support/help system is real enough to track, but still clearly early and intentionally constrained.
Medium Foundation Exists 46%

Target: operational, trial

Last reviewed: 2026-05-15. Source: Repo audit against support-agent routes, services, UI, and docs.

Feature maturity 46%
Evidence links (4)
Remaining gaps (2)
  • The support agent is still a guarded foundation rather than a mature daily-use assistant. medium
  • Operational readiness depends on better curation of staff-safe help coverage and escalation boundaries. medium
Recommended next tasks (2)
  • Track support-agent maturity by coverage, safety, and operator usefulness rather than mere route existence. medium
  • Link help-system maturity to diagnostics and support-doc completeness in the dashboard summary. medium
Ideas and dependencies

Ideas

  • Create a dedicated help-system maturity ladder for guarded tooling, staff docs, and escalation support.

Dependencies

  • Diagnostics, support packs, and operational readiness
  • Permissions and sensitive action hardening