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

Phase 6 and 7 scope contact safeguards

Browse Source
This commit is contained in:
Codex
2026-07-10 14:14:23 -05:00
parent 6ce2b294d0
commit 5009269907
27 changed files with 1158 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/DEPLOYMENT.md
+5 -2
View File
@@ -18,6 +18,8 @@ This document records the explicit runtime requirements and server changes for P
- `openssl`
- `pdo`
- `pdo_sqlite` for SQLite test deployments and the default automated test suite
- `sqlite3` for SQLite-backed local tests
- `gd` for generated image upload fixtures and image handling
- `session`
- `tokenizer`
- `xml`
@@ -37,8 +39,9 @@ This document records the explicit runtime requirements and server changes for P
## Local Test Requirements
- The default PHPUnit configuration uses an in-memory SQLite database, so whichever PHP runtime executes `php artisan test` must include `pdo_sqlite` and `sqlite3`.
- On Windows, `php -m` should list both `PDO` and `pdo_sqlite`; otherwise the feature tests fail before reaching app code with `could not find driver`.
- WSL Ubuntu is acceptable for local verification when Windows PHP is missing SQLite support, as long as WSL PHP has `pdo_sqlite` and `sqlite3`.
- Upload tests also require `fileinfo` for MIME detection and `gd` for generated image fixtures.
- On Windows, `php -m` should list `PDO`, `pdo_sqlite`, `sqlite3`, `fileinfo`, and `gd`; otherwise the feature tests fail before reaching app code or upload assertions.
- WSL Ubuntu is acceptable for local verification when Windows PHP is missing extension support, as long as WSL PHP has the same extensions.
## Recommended Production Runtime
docs/FORWARD_PHASE_PLAN.md
+34 -18
View File
@@ -1,6 +1,6 @@
# Forward Phase Plan
This plan starts from the current Provider Exchange codebase as of commit `926455b` and reconciles the previous Phase 5-10 plan with the Field Nation product research captured on July 10, 2026.
This plan starts from the current Provider Exchange codebase and reconciles the previous Phase 5-10 plan with the Field Nation product research captured on July 10, 2026.
The goal is not to clone Field Nation. The goal is to keep the useful operational patterns while designing against the exact provider-hostile problems we observed: opaque scoring, catch-all scope language, unreachable buyer contacts, weak filtering safeguards, and work-order ambiguity.
@@ -14,9 +14,9 @@ The goal is not to clone Field Nation. The goal is to keep the useful operationa
- Buyer profiles with public/private section visibility, company description, service categories, hiring regions, structured hiring policies, locations, vendor onboarding, payment terms, website, contact email, public contact toggle, private notes, attachments, and ratings.
- Public provider and buyer directories with basic keyword filters, text-field filters, public-contact filter, sort by newest/name/rating, result counts, filter badges, and card views.
- Community feed posts and comments.
- Buyer job posts with title, status, service category, location, start time, time window, scope, required skills, required tools, deliverables, payment terms, vendor onboarding, visibility, comments, attachments, quotes, ratings, and accepted work-order creation.
- Buyer job posts with title, status, service category, location, start time, time window, scope, structured scope fields, requirements, closeout rules, support/contact certification, risk flags, payment terms, vendor onboarding, visibility, comments, attachments, quotes, ratings, and accepted work-order creation.
- Provider quote submission, quote revision history, quote decline flow, and buyer quote acceptance.
- Work orders created from accepted quotes with buyer/provider participants, status transitions, timestamps, agreed terms, checklist items, checklist completion state, evidence requirements, evidence rules, change-request JSON records, completion notes, messages, attachments, print packet, reviews, disputes, and ratings.
- Work orders created from accepted quotes with buyer/provider participants, status transitions, timestamps, agreed terms, checklist items, checklist completion state, evidence requirements, evidence rules, scope/contact snapshots, first-class change requests, contact/support events, completion notes, messages, attachments, print packet, reviews, disputes, and ratings.
- Work-order status flow: assigned, en route, onsite, in progress, completed, buyer approved, disputed, closed, cancelled.
- Mutual work-order reviews with five-star overall rating and category ratings for communication, scope accuracy, payment reliability, workmanship, and timeliness.
- Universal ratings for provider profiles, buyer profiles, job posts, work orders, and disputes.
@@ -29,13 +29,11 @@ The goal is not to clone Field Nation. The goal is to keep the useful operationa
### Current Weak Spots In Code
- Job posting still centers on a single free-form `scope` field, which allows the exact catch-all work-order behavior we want to prevent.
- Job posts do not yet have explicit fields for primary objective, included work, excluded work, maximum onsite expectation, schedule type, support/contact certification, escalation path, risk flags, or scope-clarity status.
- 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 has good sections, but contact availability, support failure logging, schedule update requests, running-late records, and report-problem records are not first-class workflow events yet.
- Change requests exist only as JSON on the work order, with no status lifecycle, approval/denial path, price/time impact, or dispute linkage.
- Disputes have votes, but reason codes are free text and do not yet include structured categories such as scope expansion, unreachable contact, missing deliverable, payment issue, or buyer support failure.
- 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.
- 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.
- External profile imports store summary numbers and notes, but not structured work-category history, imported endorsement categories, imported review snapshots with privacy controls, or imported-vs-native display rules.
@@ -171,6 +169,18 @@ Provider-protection rules:
- Undefined scope should not become provider fault.
- Dispute reasons should distinguish poor provider performance from buyer-created ambiguity.
Implementation status:
- Completed first implementation pass.
- Added structured job scope fields and support/contact certification fields.
- Added computed scope clarity and risk flags on jobs and work orders.
- Snapshotted scope and contact commitments when a quote becomes a work order.
- Converted change requests to first-class records with reason and impact fields while preserving legacy JSON fallback.
- Added contact/support event records for contact failed, support unavailable, site contact unavailable, and contact reached.
- Added print packet visibility for scope safeguards, support contacts, change requests, and contact/support events.
- Added reason codes to disputes and peer votes.
- Verified with Windows `php artisan test`.
## Phase 7 - Contact Accountability And Support Availability
Purpose:
@@ -223,6 +233,17 @@ Provider-protection rules:
- If contacts fail, that should be evidence, not a buried message.
- Buyer reliability should include support availability, not only payment.
Implementation status:
- Completed first implementation pass alongside Phase 6.
- Job creation now captures primary, backup, dispatch, bridge, escalation, support channel, response time, support window, and certification.
- Work orders preserve the accepted job contact snapshot.
- Providers can log contact/support events as evidence.
- Contact issue counts show on the work-order detail.
- Print packets include contact/support coverage and logged contact events.
- Dispute reason codes include unreachable contact and support unavailable.
- Verified with Windows `php artisan test`.
## Phase 8 - Available Work Board And Filtering System
Purpose:
@@ -661,16 +682,11 @@ Provider-protection rules:
## Recommended Immediate Sequence
1. Phase 5A: review category definitions, review response, edit window, and report flow.
2. Phase 5B: moderation queue for reported reviews and rating governance docs in the UI.
3. Phase 6A: structured job scope fields and anti-catch-all guardrails.
4. Phase 6B: risk badges and scope clarity indicators on job list/detail.
5. Phase 7A: contact/support certification fields on job posts and work orders.
6. Phase 7B: provider contact-failure/support-unavailable event logging.
7. Phase 8A: dense available-work board with compact filters.
8. Phase 9A: taxonomy tables and starter work-category seeds.
9. Phase 10A: guided imported-history wizard.
10. Phase 11A: mobile-safe API endpoints for onsite work-order actions.
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.
## Key Design Commitments
docs/INSTALL.md
+1 -1
View File
@@ -38,7 +38,7 @@ The preferred working loop for this project is:
## Important Notes
- The installer is a first-pass Ubuntu/Nginx helper, not a universal hosting panel installer.
- Local and CI test runners need PHP SQLite support: `pdo_sqlite` and `sqlite3`.
- Local and CI test runners need PHP SQLite and upload-test support: `pdo_sqlite`, `sqlite3`, `fileinfo`, and `gd`.
- Public attachment serving needs `php artisan storage:link`; the checked-in update script runs this automatically.
- Tune upload policy with `TSE_ATTACHMENT_DISK`, `TSE_ATTACHMENT_ROOT`, `TSE_ATTACHMENT_MAX_KB`, and `TSE_ATTACHMENT_MIME_TYPES`.
- Review `.env` before production use.
docs/ROADMAP.md
+17 -5
View File
@@ -13,6 +13,9 @@ Provider Exchange is a Laravel application for a provider-centered field-service
- Quote revisions, quote decline flow, and quote acceptance.
- Work-order creation from accepted quotes.
- Work-order status transitions, messages, attachments, deliverables, and completion notes.
- 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.
- 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.
@@ -39,8 +42,8 @@ Provider Exchange is a Laravel application for a provider-centered field-service
3. Asset and storage management: configurable upload roots, file policy, attachment previews, deletion, and update-path storage link handling.
4. Work-order depth: checklist templates, required evidence rules, appointment windows, onsite timestamps, change-request records, and print/PDF export for work-order packets.
5. Reputation refinement: rating category definitions, anti-abuse controls, edit windows, report flows, and moderation views.
6. Dispute workflow: better evidence timelines, reason-coded votes, quorum/visibility rules, and admin/community moderation tools.
7. Notifications: channel preferences, email templates, and event-specific subscription controls.
6. Scope clarity and work-order safeguards: structured job scope, risk badges, anti-catch-all rules, first-class change requests, and reason-coded dispute paths.
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.
@@ -50,10 +53,8 @@ Provider Exchange is a Laravel application for a provider-centered field-service
## Phase Checkpoint
Phases 1-5 have been implemented locally. Phases 1-4 have been shipped through the local -> GitHub -> ChristIT update workflow; Phase 5 is ready for the next ship/update pass. The next active planning block is:
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:
6. Dispute workflow: better evidence timelines, reason-coded votes, scope-expansion and unreachable-contact reasons, quorum/visibility rules, and admin/community moderation tools.
7. Notifications: channel preferences, email templates, and event-specific subscription controls.
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.
@@ -83,6 +84,17 @@ Phase 5 implementation completed:
- Review edits are limited by a configurable edit window.
- Imported marketplace history is labeled separately from native TSE reputation.
Phase 6/7 implementation completed:
- Job posts now include structured scope fields for primary objective, included work, excluded work, maximum onsite expectations, duration, requirements, closeout conditions, equipment expectations, return shipment, access notes, restrictions, and supplemental instructions.
- Supplemental instructions are explicitly treated as reference material that cannot override structured scope boundaries.
- Job cards, job detail, and work orders show scope clarity, support certification, and computed risk badges.
- Accepted quotes snapshot the job scope and contact/support commitments into the work order.
- Change requests are first-class records with reason code, scope impact, schedule impact, terms impact, status, responder, and resolution notes.
- Providers can log contact failed, support unavailable, site contact unavailable, or contact reached events with channel, time, result, and notes.
- 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.
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.