gracepress/technical-services-exchange
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 8 and 9 marketplace matching

Browse Source
This commit is contained in:
Codex
2026-07-10 14:27:51 -05:00
parent 5009269907
commit 24f73084fa
21 changed files with 778 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/FORWARD_PHASE_PLAN.md
+31 -6
View File
@@ -32,7 +32,7 @@ The goal is not to clone Field Nation. The goal is to keep the useful operationa
- Job posting now has structured scope and support certification fields, but the creation UI should be refined into reusable templates and stronger validation before real marketplace use.
- Provider and buyer directories use text-based filters instead of normalized category, skill, coverage, remote, rating, and reliability filters.
- Work-order lists are card-based and lack the dense assigned/available-work table that worked well in Field Nation.
- Work-order detail now supports contact/support failure logging and first-class change requests, but schedule update requests, running-late records, and general report-problem records still need a dedicated workflow.
- Work-order detail now supports contact/support failure logging and first-class change requests, but schedule update requests, running-late records, post-work tag verification, and general report-problem records still need a dedicated workflow.
- Disputes and votes now have reason codes, but quorum rules, visibility rules, and deeper evidence timelines still need a future pass.
- Reviews exist, but there is no review response, report flow, edit window, moderation queue, category definitions page, or imported/native reputation distinction in the UI.
- Universal ratings are flexible, but category names are arbitrary strings and not governed by a taxonomy.
@@ -310,6 +310,14 @@ Provider-protection rules:
- Jobs should not rank purely by buyer preference or low provider rate.
- Risk flags should be visible before a provider opens the work order.
Implementation status:
- Completed first implementation pass alongside Phase 9.
- Replaced the jobs list with a denser available-work board.
- Added filters for category, technician level, scope clarity, support certification, remote eligibility, and hide risky jobs.
- Added columns for buyer, location, category, specialty, technician level, schedule, work mode, pay type, terms summary, quote count, scope clarity, support certification, and risk badges.
- Verified with Windows `php artisan test`.
## Phase 9 - Taxonomy, Competency Tags, And Profile Evidence
Purpose:
@@ -397,6 +405,23 @@ Provider-protection rules:
- Buyers should not be able to demand advanced work while labeling it smart hands.
- Certification proof should be controlled by the provider and privacy-aware.
Implementation status:
- Completed first implementation pass alongside Phase 8.
- Added `taxonomy_terms` for categories, specialties, skills, tools, and certifications.
- Added provider/tag pivot records with evidence sources.
- Added starter seed taxonomy for field-service categories and common traits/tools/certifications.
- Added explicit technician level definitions:
- Level 1 smart hands,
- Level 2 installer,
- Level 3 troubleshooter,
- Level 4 specialist,
- Level 5 project lead.
- Added provider maximum technician level and self-declared tags in profile editing.
- Added buyer job technician-level selection and scope mismatch risk detection for smart-hands jobs that include troubleshooting or certification requirements.
- Added provider directory filters for technician level and taxonomy tag.
- Deferred buyer post-work tag endorsement/disagreement to the next verification pass.
## Phase 10 - Import Tooling And Marketplace History
Purpose:
@@ -682,11 +707,11 @@ Provider-protection rules:
## Recommended Immediate Sequence
1. Phase 8A: dense available-work board with compact filters.
2. Phase 8B: saved searches, risk filter chips, and provider default filters.
3. Phase 9A: taxonomy tables and starter work-category seeds.
4. Phase 10A: guided imported-history wizard.
5. Phase 11A: mobile-safe API endpoints for onsite work-order actions.
1. Post-work provider tag verification: buyer endorsement/disagreement with self-declared level and tags after completed work orders.
2. Phase 10A: guided imported-history wizard.
3. Phase 11A: mobile-safe API endpoints for onsite work-order actions.
4. Phase 12A: notification preference UI and event-channel controls.
5. Phase 13A: audit logs and moderation/operations queues.
## Key Design Commitments
docs/ROADMAP.md
+22 -3
View File
@@ -16,6 +16,9 @@ Provider Exchange is a Laravel application for a provider-centered field-service
- Structured job scope, scope clarity status, risk badges, and anti-catch-all supplemental instruction guardrails.
- Buyer contact/support certification, work-order contact snapshots, and provider contact/support failure logging.
- First-class work-order change requests with reason codes, impact fields, status lifecycle, and print-packet visibility.
- Dense available-work board with filters for category, technician level, scope clarity, support certification, remote eligibility, and risk suppression.
- Normalized starter taxonomy for work categories, specialties, skills, tools, certifications, and provider tag evidence sources.
- Explicit technician level ladder from smart hands through project lead.
- Configurable attachment storage policy with upload root, disk, size cap, MIME allowlist, image previews, file metadata, and deletion.
- Mutual reviews with category metrics.
- Peer-review disputes with comments, evidence, structured recommendations, and public vote breakdowns.
@@ -46,18 +49,18 @@ Provider Exchange is a Laravel application for a provider-centered field-service
7. Contact accountability and support availability: certified contacts, support windows, event logs for failed support/contact attempts, and contact reliability evidence.
8. API/mobile prep: token-scoped endpoints, versioned API resources, geolocation check-in groundwork, and mobile-safe work-order actions.
9. Import tooling: guided manual imports for Field Nation, WorkMarket, and similar profile/review history.
10. Competency tags and levels: provider/buyer tag taxonomies, smart-hands entry lane, specialty tags such as network, POTS, POS, AV, cabling, installer, and troubleshooter, plus earned level badges based on completed work and reputation signals.
10. Post-work verification: buyer endorsement or disagreement with provider level/tags after completed work orders, earned evidence upgrades, and transparent tag history.
11. Admin operations: audit logs, queue health, system status, content moderation, and backup/export workflows.
12. Deployment hardening: production environment docs, queue worker setup, scheduler setup, storage policy, and server provisioning notes.
13. License and runtime audit: generate and review PHP and JavaScript dependency license reports before adding external theme kits, map any risky package to a replacement, and keep required local/runtime extensions such as `pdo_sqlite` documented for testability.
## Phase Checkpoint
Phases 1-7 have been implemented locally. Phases 1-5 have been shipped through the local -> GitHub -> ChristIT update workflow. Phase 6/7 is ready for the next ship/update pass. The next active planning block is:
Phases 1-9 have been implemented locally through the combined Phase 8/9 marketplace matching pass. The next active planning block is:
8. API/mobile prep: token-scoped endpoints, versioned API resources, geolocation check-in groundwork, contact/support failure logging, and mobile-safe work-order actions.
9. Import tooling: guided manual imports for Field Nation, WorkMarket, and similar profile/review history.
10. Competency tags and levels: provider/buyer tag taxonomies, smart-hands entry lane, specialty tags such as network, POTS, POS, AV, cabling, installer, and troubleshooter, plus earned level badges based on completed work and reputation signals.
10. Post-work verification: buyer endorsement or disagreement with provider level/tags after completed work orders, earned evidence upgrades, and transparent tag history.
Work-order safeguards to carry into the next implementation passes:
@@ -95,6 +98,22 @@ Phase 6/7 implementation completed:
- Work-order print packets include scope safeguards, contact/support coverage, change requests, and contact/support events.
- Disputes and peer votes now support reason codes such as scope expansion, unreachable contact, support unavailable, payment issue, and insufficient evidence.
Phase 8/9 implementation completed:
- The available jobs page is now a dense marketplace board with compact filters for work category, technician level, scope clarity, support certification, remote eligibility, and hide-risky mode.
- Job rows expose buyer, location, category, specialty, requested technician level, schedule, pay type, posted terms summary, quote count, scope clarity, support certification, and risk badges.
- Technician levels are defined in `config/technician-levels.php`:
- Level 1 smart hands,
- Level 2 installer,
- Level 3 troubleshooter,
- Level 4 specialist,
- Level 5 project lead.
- Buyer job creation now requires a technician level and work mode, and can select normalized category/specialty plus pay type and posted terms summary.
- The app now has normalized taxonomy terms for work categories, specialties, skills, tools, and certifications.
- Provider profiles can declare a maximum technician level and self-declared taxonomy tags.
- Provider directory filters can match technician level and taxonomy tags.
- Taxonomy tag pivots track an evidence source, currently `self_declared`, with room for buyer endorsed, completed work, certification verified, and admin verified evidence.
Available-work safeguards to carry into directory and job-list phases:
- Available jobs should expose pay type, provider terms, schedule type, work type, rough location, buyer reliability, support/contact certification, scope clarity status, and request/quote count.