# Current Product Roadmap

This roadmap starts from the current Provider Exchange / Technical Services Exchange codebase, not from the original prototype plan.

The current app already has a working Laravel foundation: authentication, roles, provider and buyer profiles, job posts, quotes, work orders, reviews, disputes, attachments, notifications, moderation, audit logs, mobile-safe API groundwork, deployment scripts, and first-pass UX polish.

The end goal is a provider-centered technical services exchange where independent field technicians and buyers can find each other, define clear work, quote and accept jobs, preserve evidence, build mutual reputation, and resolve disputes without the platform becoming the boss, bank, rate-setter, or opaque reputation authority.

## Product Commitments

- Keep the project open source and commercially usable.
- Do not hold payment in the platform until a deliberate compliant payment partner phase exists.
- Do not set, recommend, or pressure market rates.
- Let providers control their own rates, terms, proof, availability, and imported history.
- Let buyers control posted offer terms while requiring clear scope and support commitments.
- Make ambiguous scope, unsupported scope expansion, and unreachable contacts visible before they damage provider reputation.
- Keep reputation mutual, readable, appealable, and evidence-backed.
- Keep imported marketplace history separate from native TSE reputation.
- Treat disputes as peer-review reputation records, not legal adjudication.
- Prefer measured hardening from real workflows over speculative feature expansion.

## Current Baseline

The current codebase should be treated as a prototype-complete foundation with first-pass implementations through UX/accessibility polish. It is not a mature marketplace yet.

Implemented enough to build on:

- Provider, buyer, job, quote, work-order, review, dispute, attachment, notification, moderation, audit, taxonomy, import, and API primitives.
- Scope and contact safeguards in job posts and work orders.
- Role-aware work-order transitions and mobile-safe work-order API actions.
- Admin moderation queues and audit-log visibility.
- Deployment, backup, health-check, and update scripts.

Still immature or deferred:

- Real workflow validation with providers and buyers.
- Urgent Field Nation and WorkMarket import from provider-owned source material.
- Saved searches and stronger matching preferences.
- Production-grade reputation aggregates and explainable operational metrics.
- Real email and push delivery.
- Native mobile app requirements.
- Deeper admin operations, safety actions, system health, and queue health.
- Work-order templates and reusable checklists.
- Dispute quorum, visibility, and evidence timeline rules.
- Better structured profile editing for services, tools, certifications, and locations.
- Real database, object storage, queue, and observability posture for production.

## Phase 1 - Current-State Validation And Product Truth

Purpose:

Confirm what the prototype actually does for a real provider and buyer before adding more architecture.

Build:

- A guided local and live smoke-test checklist for the core workflows:
  - provider registration and profile completion;
  - buyer registration and profile completion;
  - buyer job post;
  - provider quote;
  - buyer acceptance;
  - work-order execution;
  - evidence upload;
  - contact failure;
  - change request;
  - completion and review;
  - dispute and moderation report.
- A workflow-gap report template in `docs/` that records friction by page, role, and severity.
- A small seeded scenario set for repeatable demos beyond the single default demo job.
- A route/view inventory that marks public, authenticated, provider, buyer, admin, and API surfaces.
- A current deployment check against the ChristIT `/tse` path when deployment work is in scope.

Acceptance:

- We can demonstrate the full buyer/provider workflow without hand-waving missing screens.
- Every major friction point is captured as a concrete follow-up, not a vague future phase.
- The roadmap is adjusted from observed gaps, not assumptions.

## Urgent Lane - Field Nation And WorkMarket Import

This lane is promoted ahead of the normal phase order because provider-owned Field Nation history is immediately valuable for making the exchange credible.

Detailed implementation phases live in `docs/URGENT_IMPORT_ROADMAP.md`.

Immediate sequence:

1. Add source-batch storage and upload UI for provider-owned Field Nation/WorkMarket proof. First pass complete.
2. Add provider preview and redaction workflow. Partial first pass complete.
3. Add a Field Nation parser against user-provided samples. First text-like parser pass complete.
4. Import the user's Field Nation data locally.
5. Add WorkMarket parsing after the Field Nation path is proven.
6. Add dedupe, re-import, and admin verification improvements.

Guardrail:

Do not build blind authenticated scraping as the first approach. Start with provider-supplied exports, PDFs, screenshots, copied profile text, or reports; keep raw proof private by default; and only publish provider-approved, redacted summaries.

## Phase 2 - Profile Trust And Provider Presentation

Purpose:

Make provider and buyer profiles credible enough for real marketplace discovery.

Build:

- Provider profile completion checklist.
- Buyer profile completion checklist.
- Better structured editors for services, tools, certifications, insurance, service area, availability, and locations.
- Provider gallery support for van, tools, job photos, certifications, and proof documents.
- Buyer identity/gallery support for company logo, header, locations, and example work sites.
- Clear public/private controls for every sensitive profile section.
- Imported-history privacy copy and verification-status polish.
- Admin verification workflow improvements for profile proof and imported history.

Acceptance:

- A real technician can present enough proof to be trusted without exposing private customer data.
- A real buyer can present enough company and support context for providers to judge risk.
- Profiles are filterable and readable without relying on long free-text blobs.

## Phase 3 - Matching, Search, And Saved Preferences

Purpose:

Turn the available-work board and directories into practical daily scanning tools.

Build:

- Saved job searches.
- Saved provider searches.
- Provider work preferences:
  - regions;
  - remote/onsite/hybrid;
  - categories;
  - technician level;
  - minimum terms;
  - schedule preferences;
  - hide-risk defaults.
- Advanced job filters:
  - distance or region;
  - pay floor or terms summary;
  - schedule type;
  - date range;
  - buyer rating;
  - buyer contact reliability;
  - required tools/certifications;
  - scope clarity;
  - support availability.
- Directory reliability filters for buyers and providers.
- Better empty states and result explanations for filtered boards.

Acceptance:

- A provider can quickly find work that fits their skills, region, terms, and risk tolerance.
- Buyers can find providers by evidence-backed competencies rather than keyword guesswork.
- Saved searches can later feed notification matching.

## Phase 4 - Work-Order Templates, Checklists, And Evidence Rules

Purpose:

Make clear work repeatable instead of forcing every buyer to write scopes from scratch.

Build:

- Buyer work-order templates.
- Provider suggested checklist templates.
- Category-specific checklist starter sets.
- Required evidence rules by job category and closeout condition.
- Appointment windows and onsite timestamp polish.
- Better "report problem" flow that wraps contact failure, support unavailable, scope expansion, safety/access issue, and schedule issue.
- PDF export or improved print packet path for work-order records.

Acceptance:

- Buyers can create clear jobs faster.
- Providers can see expected evidence before quoting.
- Out-of-scope or unsupported requests become structured records instead of buried messages.

## Phase 5 - Reputation, Metrics, And Provider Protection

Purpose:

Make reputation useful without becoming an opaque score.

Build:

- Cached reputation aggregates after measuring slow pages.
- Explainable operational metrics:
  - completed jobs;
  - review count;
  - average rating;
  - recent rating trend;
  - unresolved disputes;
  - contact failure reports;
  - support failure reports;
  - scope change reports.
- Separate native TSE history, imported history, and admin-verified proof.
- Review response and appeal polish.
- Rating category governance for universal ratings.
- Anti-abuse checks for duplicate or retaliatory reviews.

Acceptance:

- Reputation pages stay fast with realistic data volume.
- Providers can understand and contest reputation-impacting records.
- No hidden private feedback or unexplained composite score controls standing.

## Phase 6 - Dispute And Moderation Maturity

Purpose:

Make disputes and moderation fair, auditable, and understandable before real marketplace scale.

Build:

- Dispute evidence timeline.
- Vote quorum and visibility rules.
- Moderator notes and action history.
- User safety actions:
  - warning;
  - temporary restriction;
  - suspension;
  - restoration.
- Report queues with filters, severity, status, and assignment.
- Public/private visibility rules for dispute outcomes.
- Exportable audit packet for a work order or dispute.

Acceptance:

- A dispute can be reviewed from evidence without reading unrelated chatter.
- Moderation actions are visible to admins and auditable later.
- Reputation impact is tied to explainable outcomes.

## Phase 7 - Notifications, Email, And Matching Alerts

Purpose:

Make users aware of important activity without becoming noisy or pushy.

Build:

- Choose mail provider and configure real email delivery.
- Email templates for quote, work-order, dispute, moderation, and saved-search events.
- Preference-aware immediate and digest delivery.
- Quiet-hours enforcement for non-critical events.
- Saved-search alerts using Phase 3 preferences.
- Unsubscribe/preferences links for email.
- Push-provider decision record, if push is still desired.

Acceptance:

- Users can opt into meaningful alerts.
- Critical in-app records remain visible even if email/push is off.
- Email does not ship before sender identity, bounce handling, and unsubscribe policy are clear.

## Phase 8 - Mobile And Field Workflow

Purpose:

Turn the API groundwork into a reliable onsite workflow.

Build:

- Mobile payload review from real app or PWA requirements.
- Provider field workflow:
  - assigned work;
  - en route;
  - onsite;
  - checklist;
  - evidence upload;
  - contact failed;
  - running late;
  - change request;
  - submit completion.
- Buyer mobile workflow for approval, messages, change requests, and support escalation.
- Offline/poor-signal behavior plan.
- Geolocation copy and privacy controls.
- Token management UI for API clients.

Acceptance:

- A provider can execute a job from a phone without desktop-only screens.
- Location evidence is optional, explicit, and work-order scoped.
- API payloads are stable enough for a native app or PWA client.

## Phase 9 - Admin Operations And Production Readiness

Purpose:

Prepare the platform to operate with real users and real evidence records.

Build:

- Admin system status panel.
- Queue health panel.
- Scheduler health panel.
- Backup status and restore drill documentation.
- Slow-query and error monitoring.
- Real database deployment path from SQLite to MariaDB/MySQL or PostgreSQL.
- Redis cache/session/queue migration.
- Object/shared storage plan for uploads.
- Private evidence access controls.
- Upload quotas, malware scanning plan, and thumbnail generation.
- Log rotation and retention policy.

Acceptance:

- Operators can see whether the platform is healthy.
- Evidence and uploads are not dependent on fragile local-only assumptions.
- Production deployment has restore, monitoring, and incident paths.

## Phase 10 - Marketplace Governance And Launch Readiness

Purpose:

Move from prototype to a controlled early marketplace.

Build:

- Terms of use and privacy policy review.
- Provider onboarding guide.
- Buyer onboarding guide.
- Community standards and dispute policy.
- Open-source contribution guide.
- License audit for PHP and JavaScript dependencies.
- Pilot cohort checklist.
- Data retention policy.
- Backup and export commitments.
- Public launch checklist.

Acceptance:

- A small group of real providers and buyers can use the system with clear expectations.
- The project remains open-source friendly.
- Legal, operational, and support boundaries are explicit before broader launch.

## Deferred Until Explicitly Chosen

- Payment custody, escrow, or wallet features.
- Platform-set or recommended rates.
- Opaque provider scoring.
- Automated scraping of authenticated third-party marketplaces.
- Realtime chat or websocket presence.
- Broad native mobile app build before API requirements are validated.
- Multi-tenant SaaS packaging.

## Immediate Next Step

Start Phase 1 with a current-state workflow validation pass. The most useful first deliverable is a checklist-driven buyer/provider walkthrough that identifies which screens are already usable, which are confusing, and which missing pieces block a real pilot.

Phase 1 artifacts now live in:

- `docs/PHASE1_WORKFLOW_VALIDATION.md`
- `docs/PHASE1_GAP_REPORT_TEMPLATE.md`
- `docs/ROUTE_SURFACE_INVENTORY.md`