trades-runtime
Read-only public info from the Trades-Runtime giveaway Worker.
Health: Check runtime giveaway health (read-only, no counter increment).
Stats: View honest KV view/download counts with human/bot split (read-only).
Cite: Retrieve public cite.json for Trades-Runtime.
Skill: Get agent skill markdown for the public giveaway Worker.
Allows importing QuickBooks-shaped books (QuickBooks Online/Desktop) as a named profile in the universal trades-app drop-in, enabling local shadow processing of financial, job, and pricebook data.
Allows importing Xero books as a named profile in the universal trades-app drop-in, enabling local shadow processing of financial and job data.
Trades-Runtime
Private TypeScript runtime for a shadow-first AI operating system / company operating intelligence layer. Field trades: HVAC, plumbing, electrical, sewer, and cross-trades.
Author / identity: Aziel Eliab only. See IDENTITY.md. No legal name, home, or county on exports.
Version: 1.0.0-local (Local Softwares 1.0, installable)
Role: trades-runtime
License: Apache-2.0
Release: free software (Apache-2.0). Clone it and run the local shadow on your machine. Aziel Eliab is the author, not the operator, and is not running a company pilot.
Public Worker (if deployed): https://trades-runtime.vibelock.workers.dev
Try on Glama (intended listing): https://glama.ai/mcp/servers/AzielEliab/trades-runtime — pack is in-repo (glama.json, Dockerfile, cli/mcp-stdio.mjs). Do not treat Install Server as LIVE from this git tree alone. Checked 2026-10-02: Glama Latest/releaseVersion is 1.0.0-local. The badge matches the Softwares cite tip. Local Softwares 1.0. That match is not a Field 1.0 claim and not Office Softwares 1.0. This cut does not Make Release. See docs/GLAMA.md.
Status: 1.0.0-local installable Local Softwares 1.0 (Track L gate; pilot not started; live_backends false; not a Field 1.0 claim) — 0.4.12 familiar commands (help, softwares, version, health) so a person can discover the product without reading the whole README; desk features stay frozen (pilot not started) — 0.4.11 giveaway human UI on the VibeLock Worker (browser / PWA) without downloading first; optional counted pack; operator desk still local (pilot not started) — 0.4.10 local time tracking, service-coverage switches, and right-tech suggestions on the Monitoring desk (pilot not started) — 0.4.9 local inbound quality report for ServiceTitan and ProBooks fragments, alert-to-action stubs with refused write-back, and an Option C start-gate prep panel (pilot not started) — 0.4.8 local miles driven and drive performance, a ranked employee and department performance board, work-together suggestions across departments, and an employee friction rate beside that board (pilot not started) — 0.4.7 part cost with regional market adaptation, per-tech trainingNeeded, good and bad department behavior flags, and local truck counts (pilot not started) — 0.4.6 per-call classify reasons, callback / warranty / not-classified filters, a loopback weekly callback-rate digest, and a tech morning huddle (pilot not started) — 0.4.5 local callback and warranty counts, alert-digest export, score explanations, and booking-block receipt (pilot not started) — 0.4.4 local operator desk polish (theme, lane view, printable snapshot; pilot not started) — 0.4.3 Option C BYO pilot prep (local runbook + npm run pilot:prep; pilot not started) — 0.4.2 local alert rules on the operator desk — 0.4.1 named trades-app vendor profiles on the 0.4.0 universal drop-in — lockstep with Property Intelligence v1.0 in-tree — live-pure core + honest stubs — BYO local ServiceTitan + ProBooks + trades-app inbound — no live writes, tenant data, ST/ProBooks write-back, phone-home, DOIs, hosted uploader, or production company-OS claim — Option C code-ready / pilot not started — Option D not started
The product is the software in src/. docs/ is a thin local catalog/UI. GitHub Pages is intentionally disabled (live_backends: false). There is no Pages workflow. PDFs are never published. Implementer specs live at repo-root specs/ (not under docs/).
Standing rule: every PDF Aziel sends is a spec to implement as coded software.
Paper trail: TR-1.0-GATE-2026-09-28 (Track L Local Softwares 1.0 gate; pilot not started) · TR-COMMANDS-2026-09-27 (common CLI commands help, softwares, version, health; desk frozen; pilot not started) · TR-OPS-2026-09-27 (local time tracking, coverage switches, right-tech suggestions; pilot not started) · TR-DESK-VIEW-2026-09-27 (local show/hide checkboxes; Softwares card grids unchanged; pilot not started) · TR-MOBILE-DESK-2026-09-27 (phone-width local desk; Softwares cards unchanged; pilot not started) · TR-QUALITY-2026-09-27 (inbound quality, alert-action stubs, Option C start gate; pilot not started) · TR-DRIVE-2026-09-27 (miles driven, drive performance, ranked employee and department board; pilot not started) · TR-SOFTWARES-2026-09-27 (part cost and market adaptation, trainingNeeded, department behavior flags, local truck counts; pilot not started) · TR-HUDDLE-2026-09-26 (per-call classify reason, call filters, weekly callback rate, morning huddle; pilot not started) · TR-CALLS-2026-09-26 (callback and warranty counts, alert digest, score why, booking-block receipt; pilot not started) · TR-DESK-POLISH-2026-09-25 (local desk polish; pilot not started) · TR-OPTION-C-PILOT-RUNBOOK-2026-10-02 (human Option C start path; catalog pilot not started) · TR-PILOT-START-2026-10-02 (explicit pilot:start --branch on the operator isolate; not Field 1.0; not Office Softwares 1.0) · TR-OPTION-C-PREP-2026-09-25 (Option C box prep; pilot not started) · TR-ALERTS-2026-09-25 (local alert rules) · TR-VENDOR-2026-09-25 (named vendor profiles) · TR-DESK-2026-09-25 (universal drop-in + local human desk) · TR-AUDIT-2026-09-18C · TR-AUDIT-2026-09-18B · TR-AUDIT-2026-09-18 · TR-AUDIT-2026-09-17 · TR-CUT-2026-09-17 · TR-BOT-2026-09-17 (standing brief) · TR-BYO-2026-09-17 (amends TR-BOT §9 and TR-CUT R2–R3).
Try it on your machine
Merging this repository does not start a pilot. Aziel Eliab wrote the software. He is not the operator, he is not a customer, and he is not running a shop on this repo. live_backends stays false. There is no write-back. A fresh clone needs no ServiceTitan or ProBooks tenant and no secrets.
git clone https://github.com/AzielEliab/trades-runtime.git
cd trades-runtime
npm install
npm test
npm run demo
npm run shadow:office
npm run shadow:field
npm run deskWhat you will see:
npm run demoprints a synthetic shadow day in the terminal. It is a fixture. It is not a company result and it does not print an accuracy percent.npm run shadow:officeruns the office shadow on the sample branch namedsample-shop. Fixtures are already intest/fixtures/sample-branch/office/. The receipt saysoffice_softwares_1_0: false,pilot_started: false, andlive_backends: false. You will see admitted sample jobs, a huddle count, inbound quality as a checklist, and alert stubs that refuse write-back. That command does not load field flags.npm run shadow:fieldruns the field shadow on the same sample branch, fromtest/fixtures/sample-branch/field/. You will see local flags (needsParts,safetyHold,vanDown, and a row that names a label without a van, which does not invent a van), a time card, coverage places, and a right-tech suggestion.field_softwares_1_0is false. It is not a live GPS feed and not Field 1.0. It is a separate command from the office shadow.npm run deskopens the local desk at http://127.0.0.1:4174/ . With empty inbound folders the page is labeled synthetic demo. It is not your company and not a live tenant. Dropping your own exports intodata/inbound/is optional and stays on your machine.
When you have a real branch on your own machine, and only then:
npm run pilot:prep
npm run pilot:start -- --branch <branchId>That is the only software path that sets pilot_started true, and it does it on your isolate only. It refuses a missing or bad branch, prep that is not ready, and --claim-company when inbound is empty or only synthetic. The shipped catalog stays pilot_started false. Mode stays SHADOW-SEALED. Writes stay refused. The receipt is not a live company OS, not Office Softwares 1.0, and not Field 1.0.
Related MCP server: NeuroLink
Install, test, demo
npm install
npm test
npm run typecheck
npx tsx src/cli.ts help
npx tsx src/cli.ts softwares
npx tsx src/cli.ts version
npx tsx src/cli.ts health
npm run demo
npm run byo:admit-demo
npm run drop-in:demo
npm run desk
npm run shadow:office
npm run shadow:field
npm run pilot:prep
npm run pilot:start -- --branch <branchId>
npm run health:local
npm run shadow:sealed-demo
npm run manifest
npm run mcphelp prints the command list (--help and -h do the same). softwares lists each module's slug, status, and one line in plain language (Softwares matches in any letter case). version prints the product name and version, then one honesty line: live_backends false, pilot_started false (--version and -V do the same). health is the same local honesty card as health-local. An unknown command prints that it is unknown, then the help text, and exits non-zero. No command still prints help and exits zero.
npm test runs constitutional rule tests including Human Authority, confidence≠truth, CrossTrade secondary-only routing, v0.2 recognition / pricebook lock / mission board / location economics, the 0.3.3 execution spine (FragGate inbound, durable receipts, runAction), restart-replay of append-only JSONL receipts (data/receipts.jsonl or {tmpdir}/tr-replay-*/receipts.jsonl), the synthetic BYO admit demo, the universal drop-in demo, the local operator desk, Option C sealed-shadow scaffolding (no auto-promote, engagement drop-back, required settlement fields), and Option C pilot prep (machine checks, synthetic admit, desk boot, pilot_started: false).
CI (.github/workflows/ci.yml) runs npm ci, npm run typecheck, and npm test on pull requests and pushes to main. GitHub Pages is intentionally disabled — do not treat a github.io URL as a test gate.
npm run demo runs a synthetic shadow-day: Call-Fit, sealed counterfactual, human override, hash-chained receipts, trajectory rebase.
Software map
Area | Path | Status |
Canonical IDs / events / modes |
| live-pure |
Confidence ≠ truth |
| live-pure |
Chains A/B/C/D |
| live-pure |
Human Authority |
| live-pure |
TradesCoherence, EvidencePacket, DecisionGate, ReceiptLedger, Shadow, Trajectory |
| live-pure |
Call-Fit, economics, CrossTrade, Chain D, workforce, Decision Fabric, analytics |
| live-pure |
Communications (event-stream channels) |
| live-pure |
Recognition (quality-gated) |
| live-pure |
Daily mission board |
| live-pure |
Callback and warranty labels |
| live-pure |
Morning huddle + trainingNeeded |
| live-pure |
Miles driven and drive performance |
| live-pure |
Ranked employee and department board |
| live-pure |
Work together and cross-department suggestions |
| live-pure |
Employee friction rate |
| live-pure |
Inbound quality report |
| live-pure |
Alert action stubs |
| live-pure |
Option C start gate |
| live-pure |
Local positions and Monitoring view |
| live-pure |
Pricebook (ST shadow + current/last cost + LOCK) |
| live-pure |
Truck stock counts / fulfillment |
| live-pure |
Weather / demand / lunar (experimental) |
| live-pure |
Maintenance routing (demand-first) |
| live-pure |
Property Intelligence v1.0 |
| live-pure |
FragGate inbound |
| live-pure |
Durable receipts |
| live-pure |
|
| live-pure |
Actor / authority registry |
| live-pure |
Shadow modes |
| live-pure |
Engagement rules (not an order) |
| live-pure |
One-branch shadow config |
| live-pure |
Settlement harness |
| live-pure |
ServiceTitan shadow (read-only) |
| live-pure |
ProBooks shadow (read-only, peer inbound) |
| live-pure |
Local BYO inbound layout |
| live-pure |
Local inbound config (no cloud account) |
| live-pure |
Universal trades-app drop-in |
| live-pure |
Trades-app shadow (read-only) |
| live-pure |
Local human operator desk |
| live-pure |
Synthetic drop-in demo |
| live-pure |
Runtime isolate (per-instance receipts) |
| live-pure |
Synthetic BYO admit demo |
| live-pure |
Synthetic sealed-shadow demo |
| live-pure |
Option C pilot prep |
| live-pure |
Local health card |
| live-pure |
Fulfillment state machine |
| live-pure |
Mission board clock |
| live-pure |
PI wired to jobs |
| live-pure |
§18 freeze + v0.2 governing rules |
| live-pure |
ServiceTitan / ProBooks live writes | — | refused |
BYO inbound (TR-BYO-2026-09-17)
Each user incorporates their own ServiceTitan and their own ProBooks into their local runtime. The authoring node / GitHub is not a data custodian. No central dump. No hosted uploader. No phone-home.
Local inbound on that machine (contents gitignored):
data/inbound/servicetitan/— ST export or read-only pull the user placesdata/inbound/probooks/— ProBooks books / items / costs / vendor files the user placesdata/inbound/trades-app/— other field-service / job / pricebook / customer / appointment exports. Named profiles: Jobber, Housecall Pro, Service Fusion, QuickBooks-shaped books, ServiceM8, AccuLynx, SuccessWare, Xero, FieldEdge, ServiceTrade. Generic CSV/JSON when no fingerprint matches.data/runtime/<instanceId>/receipts.jsonlandledger.jsonl— isolate per runtime instance
Not data/tenants/ (that word implies a hosted multi-tenant service). Optional local config lists paths or read-endpoint hints only — no cloud account, and the runtime does not call those hints. Tokens stay on the user’s machine or their sealed vault.
FragGate first-class sourceKind values: servicetitan (MEDIUM, hashed, live:false write:false), probooks (same), trades-app (same, generic class), operator-file (LOW until origin tagged servicetitan, probooks, or trades-app; still not truth), human (manager correction on Chain C with actor id). Wrapper ≠ verified. Scrape, central-dump, hosted-upload, and silent promotion to VERIFIED are refused.
Universal drop-in (TR-DESK-2026-09-25)
ServiceTitan and ProBooks stay named peer classes. A third inbound class, trades-app, admits the same family of exports without a new paper for each vendor. The drop-in sniffs JSON/CSV shape and applies a mapping profile. 0.4.1 prefers a named profile when keys, headers, or the filename match: Jobber, Housecall Pro, Service Fusion, QuickBooks Online, QuickBooks Desktop, ServiceM8, AccuLynx, SuccessWare, Xero, FieldEdge, and ServiceTrade. Otherwise it uses generic JSON or generic CSV. A file that still looks like ServiceTitan or ProBooks stays on that peer class. See TR-VENDOR-2026-09-25.
npm run drop-in:demoThat demo copies synthetic fixtures from test/fixtures/byo/ into a temp inbound tree, admits them through FragGate, hashes packets, writes temp isolate receipts, and proves writes still throw. It is not a customer dump.
Real exports stay in the gitignored drop folders. data/inbound/local.json (copied from local.json.example) may name paths and read-endpoint hints. Hints are documentation for the operator. This process does not fetch them.
Human operator desk
The desk is the human surface. Agent MCP stays a read-only bridge without this chrome.
npm run desk
# http://127.0.0.1:4174/npm run shadow:field and npm run shadow:office print one local shadow read of that same desk snapshot. Both commands, and the desk page, read data/runtime/<instanceId>/field-events.jsonl (Clock in, Clock out, Start Meal, End Meal, Drive time home) and the job price record in data/runtime/<instanceId>/job-prices.json (typed part cost, labor, task fees, margin, locked discount). They do not keep a second event log. live_backends stays false. pilot_started stays false. This is not a Field 1.0 claim and not Office Softwares 1.0. ServiceTitan, Jobber, and other bring-your-own profiles stay read-only. Writes stay refused. A SupplyHouse price is present only when the stored sheet already has one. This read does not invent a price and does not add an order path. Property listing facts stay empty until a permitted source exists.
It binds to 127.0.0.1 only. The page shows job/completion charts, a capacity chart, a mission board and a tech board, a morning huddle, fulfillment progress, alerts, and scores. Callback calls, warranty calls, and a not-classified bucket sit on the metrics and the mission board. Each call row carries the classify reason when the export named a label, and says not classified when the export is silent. Filters are ?calls=callback, ?calls=warranty, and ?calls=not-classified on the page, /api/snapshot, /api/view, /api/receipt, and the SSE stream. /api/calls/week.json is the trailing-week callback rate by trade lane. /api/huddle prints the morning huddle and /api/huddle.json is the same board as JSON. The huddle names trainingNeeded (severity and reason) from procedure observations. It is not a skill score. Part cost, department behavior, and truck counts are on the same page. /api/stock reads on-van and warehouse counts. Miles driven and drive performance sit beside a ranked employee and department performance board. /api/drive and /api/performance are the loopback JSON for those boards. An optional miles file is data/runtime/<instanceId>/drive-miles.json or data/inbound/drive-miles.json. A missing file stays unknown once a local export is admitted. The empty-folder desk labels a synthetic demo. That demo is not a company export and not a telematics feed. The rank is not a skill score and it does not set trainingNeeded. No GPS vendor is claimed. Work together lists positive collaboration from Chain D, cross-trade, and recognition flags and names who or which lane should pair or hand off for service techs when needed and for install. /api/work-together is that board. Employee friction rate sits on the same performance board and at /api/friction. It counts handoff failures, coordination flags, explicit callbacks, and delayed handoffs on this machine. A silent export stays unknown. Friction rank 1 is the highest known friction, not the best performance. It is not a hosted HR system and it does not set trainingNeeded. Those routes stay on this machine. Each score and pace band includes a short why. Current alert-rule hits export as JSON or CSV from /api/alerts/digest.json and /api/alerts/digest.csv on this machine. /api/receipt prints what blocked booking when a block is present, and says when nothing is blocking. TR-DESK-POLISH-2026-09-25 adds spacing and type, a light/dark theme stored in this browser (trades-desk-theme), a lane view, and a printable snapshot at /api/receipt. The lane is a slot count, or a known trade token when the export names one (hvac, plumbing, electrical, sewer, cross-trades). A city name is not a lane. No map is drawn. The snapshot is HTML the operator can print or save as PDF. It cites local receipt identifiers and does not include receipt bodies. Nothing on that page phones home. Scores use mission pace, the evidence trust band, verification (UNVERIFIED), and recommendBlock. Prediction confidence stays withheld on a BYO drop. The recorded synthetic shadow-day confidence appears only on the synthetic demo, labeled as a fixture. An empty inbound folder shows that synthetic demo. Dropping a file updates the next SSE tick (about 2s) and the label switches to BYO-admitted, or BYO-admitted synthetic drill when every file declares synthetic: true.
Local alert rules (TR-ALERTS-2026-09-25)
The same scores drive local thresholds: capacity (open slots, only when a lane exists), late jobs (unfinished rows against the mission clock), trust-band (evidence-trust floor or a drop remembered on this machine), booking block (recommendBlock), and verification stall (the verification score stays UNVERIFIED or CONFLICTED for N minutes from the oldest observation). No accuracy percent is computed. A missing clock does not invent a stall. Blank open slots on a BYO desk do not invent a utilization percent.
Copy data/runtime/alerts.json.example to data/runtime/<instanceId>/alerts.json (gitignored). data/inbound/local.json may set alertsPath or an alerts object. The desk banner shows unacknowledged rules. The alerts panel shows active rules, history, and acknowledge. Acknowledge is a local POST on 127.0.0.1 and writes only alert-state.json. Optional hooks append a local JSONL file or POST to loopback (127.0.0.1, localhost, ::1). Any other webhook host is refused. No phone-home.
Inbound quality, alert stubs, and Option C start gate (TR-QUALITY-2026-09-27)
/api/inbound-quality and /api/inbound-quality.txt score ServiceTitan and ProBooks fragments already on this machine. The desk charts volume by sourceKind, checklist-score distribution, and top defect classes from that local report. Empty folders use a labeled synthetic fixture. The checklist is not an accuracy percent and not a live tenant pull. Files land at data/runtime/<instanceId>/inbound-quality.json, .txt, and .jsonl.
/api/alert-actions returns stubs only. A firing alert expands to a label, a rationale, the required human authority, and refused: write-back. The Human Authority Rule is on the panel. Stubs do not call ServiceTitan or ProBooks.
/api/option-c-start-gate lists the start conditions. Every gate stays blocked-until. Option C remains prep until a human operator starts a real pilot. Option D is out of scope. There is no cutover. The shipped catalog keeps pilot_started false. live_backends stays false. The panel does not start the pilot.
/api/monitoring is one desk view: local or demo tech and truck pins, time cards, a coverage livemap, right-tech suggestions, drive score cards, tech score cards, a dispatch-style call board, and KPI charts. Pins come from data/runtime/<instanceId>/positions.json, data/inbound/positions.json, or coordinates copied off a local miles file. Copy data/runtime/positions.json.example. An empty folder uses a labeled synthetic demo. A refused file is not replaced by that demo. Mile totals still ignore coordinates. The address map stays undrawn. This is not a live GPS feed and not a telematics vendor. The view recomputes when local files change. Monitoring only. The Human Authority Rule stays on the panel. Nothing writes back to ServiceTitan or ProBooks.
/api/time-tracking is the local time board: clocked time on the current call, elapsed, estimated remaining, and idle or travel segments. Copy data/runtime/time-cards.json.example to data/runtime/<instanceId>/time-cards.json or data/inbound/time-cards.json. The desk writes time-tracking.json and time-tracking.jsonl under data/runtime/<instanceId>/. A missing file stays empty once a local export is admitted. The empty-folder desk labels a synthetic demo. That demo is not a company timeclock and not a GPS feed.
/api/coverage is zip codes, counties, cities, and roads or highways, with on/off switches. Copy data/runtime/coverage.json.example to data/runtime/<instanceId>/coverage.json or data/inbound/coverage.json. Switches persist in coverage-layers.json on this machine (POST /api/coverage/layers). Counts are places, jobs, and techs from that local file. Not a live map-tile vendor. The address map stays undrawn.
/api/right-tech (and /api/tech-fit) ranks techs for an open or scheduled job from geolocation, estimated time remaining, and skill fit. Optional ?job=. Suggestions only. No auto-dispatch. No write-back. Friction and heavy local drive minutes are flags. Geography is not the only factor.
The operator can turn boards, metrics, KPIs, techs, scores, charts, lanes, alerts, call columns, and mission measures on or off. Every box starts on. The choice is stored in this browser under trades-desk-view and is not sent off the machine. TR-DESK-VIEW-2026-09-27.
The same page is usable at about 375px. A sticky domain nav jumps to each board. Header links, monitor charts, and wide tables scroll inside the page instead of widening it. Theme, filters, acknowledge, the stub disclosure, print, and any input, select, or textarea are at least 44px tall, with safe-area padding. Wide-window Softwares card grids stay as they are. There is still no tenant data-entry form. TR-MOBILE-DESK-2026-09-27. The public Worker cards are not part of this cut.
The public Worker may cite npx tsx src/cli.ts desk and /local-desk as install notes. It does not host the desk, the alert hooks, or tenant metrics. This repo does not deploy the Worker.
npm run byo:admit-demo is operator-software proof with synthetic fixtures under test/fixtures/byo/. It copies those fixtures into a temp inbound dir, admits via FragGate as servicetitan + probooks, hashes packets, writes isolate receipts under a temp data/runtime/<id>/, prints hashes, and proves wrapper ≠ VERIFIED while ST/ProBooks writes still throw. It is not a customer dump. The authoring node is not a data custodian.
Real user exports belong only on that user's machine under data/inbound/{servicetitan,probooks,trades-app}/ (gitignored except .gitkeep).
Inherited names come only from specs/aziel-runtime-inheritance.txt. This is not a wholesale copy of aziel-runtime Softwares.
Ladder (honest)
Option | Meaning | State |
A | Merge-only | done |
B | Local spine | done in software |
C | One-branch shadow | code-ready / pilot not started |
D | Advise-lock pilot | not started |
Software for Option C exists (named branch, engagement rules, sealed settlement harness, synthetic demo). That is not a company or field pilot. Do not tell a GM the company OS is live. Do not fake Option C as a live company pilot. Option D is still NO.
TR-OPTION-C-PREP-2026-09-25 is the operator-box checklist: local install, inbound drop folders, example config, synthetic admit, desk and alerts, SHADOW-SEALED expectations, refuse-write proof, and what not to do. npm run pilot:prep runs those checks and prints a receipt. ready: true means the machine passed. That receipt keeps pilot_started false. The command does not open a sealed day against company actuals and does not write to ServiceTitan, ProBooks, or a trades app.
TR-OPTION-C-PILOT-RUNBOOK-2026-10-02 is how an operator starts a real pilot with the shipped command. After prep is green, a person on the operator box runs npm run pilot:start -- --branch <branchId> (CLI pilot-start). One named branch is required. The command reuses the prep checks. It refuses a missing or bad branch, prep that is not ready, and --claim-company when inbound is empty or only synthetic. Success writes data/runtime/<instanceId>/pilot.json and a line on receipts.jsonl for that isolate only. The shipped catalog, default health, glama.json, and the giveaway Worker pin stay 1.0.0-local with pilot_started false. Mode stays SHADOW-SEALED. live_backends stays false. Writes stay refused. An explicit mode change does not start the pilot. The receipt says this is not a live company OS, not Field 1.0, and not Office Softwares 1.0. Merging this documentation does not start a pilot. A human must run the command on a real prep-ready branch. TR-PILOT-START-2026-10-02 is the cut that shipped the command. This repository does not deploy the Worker and does not Make Release.
Still human/operator-only: a real ServiceTitan path on their box, a named GM, and sealed days against their actuals. The authoring node does not hold that dump. A prep receipt is not that pilot.
Public giveaway Worker
Operator-authorized public surface is a Cloudflare Worker:
https://trades-runtime.vibelock.workers.dev
Worker script name: trades-runtime (same vibelock workers.dev account pattern as aziel-runtime.vibelock.workers.dev). Source: workers/giveaway/.
What it is:
Human giveaway UI on this VibeLock host (browser / PWA): honesty, cite, MCP, skill, and stats, usable without downloading first
Optional counted Apache-2.0 tarball at
GET /download(increments only after a verified gzip 200)/local-deskcites the localnpx tsx src/cli.ts deskinstall. It does not host tenant metrics or a live company boardThin read-only
/openapi.jsonandPOST /mcpfor AI clients (health / stats / cite / skill only)Growth-ON crawl surfaces:
/robots.txt(full Allow + Content-Signal),/sitemap.xml,/ai.txt,/humans.txt,/.well-known/mcp.json,/person.jsonld,/graph.jsonldStdio MCP bridge for Glama / Claude Desktop / Cursor:
npm run mcp→cli/mcp-stdio.mjs(forwards to WorkerPOST /mcp)Honest Workers KV counters (
COUNTS):viewsanddownloadsstart at 0; increment only on successful 200 responses; no sampling, no seed, no inflation
Deploy (operator / box with wrangler auth)
This repository does not deploy the Worker. First time on the vibelock account:
npm ci
npm test
cd workers/giveaway
npm ci
npx wrangler kv namespace create COUNTS
# paste the printed id into wrangler.jsonc kv_namespaces[0].id
npm run pack
npx wrangler deployLater deploys from repo root:
npm run giveaway:pack
cd workers/giveaway && npx wrangler deployLocal smoke (Miniflare KV, no Cloudflare auth required):
npm run giveaway:pack
cd workers/giveaway
npx wrangler dev
# GET http://127.0.0.1:8787/ /download /v1/health /v1/stats /robots.txt /sitemap.xml /ai.txtCounters: see workers/giveaway/README.md.
Glama (Install Server pack)
Intended listing: Try on Glama
The listing URL is documented so agents and humans can find it. The Git pack (glama.json + Dockerfile + cli/mcp-stdio.mjs) is what Glama needs to index and host a stdio process. Install Server is not claimed LIVE from this git tree alone. Steps: docs/GLAMA.md.
Do not invent Glama TDQS scores. The listing Latest matches the Softwares cite tip. That match is not Field 1.0 and not Office Softwares 1.0.
Checked 2026-10-02: Glama Latest/releaseVersion is 1.0.0-local (latestRelease.version on https://glama.ai/mcp/servers/@AzielEliab/trades-runtime). The badge matches the Softwares cite tip. Local Softwares 1.0. That match is not a Field 1.0 claim and not Office Softwares 1.0. glama.json version is the in-repo claim file (1.0.0-local) and matches that badge. The Worker source in this repo is 1.0.0-local. The giveaway Worker version pin is 1.0.0-local. Checked 2026-09-28: the already-running Worker is still 0.4.12. This cut does not deploy and does not Make Release. pilot_started false. live_backends false.
Local / Docker:
npm run mcp
# or
node cli/mcp-stdio.mjs
docker build -t trades-runtime-mcp .
docker run --rm -i trades-runtime-mcpPages (intentionally disabled)
GitHub Pages is intentionally disabled. There is no .github/workflows/pages.yml. Do not add a Pages deploy workflow. Do not enable Pages on the repository. Do not treat a github.io URL as a live product surface.
The software is free to clone. GitHub Pages stays off. Do not enable Pages. Do not add PDFs under docs/. A browser UI, if a Worker is already deployed, is https://trades-runtime.vibelock.workers.dev. This repository does not deploy that Worker. The counted tarball is optional.
Local UI preview (Pages stay off):
python3 -m http.server 4173 --directory docsMachine catalog: docs/v1/runtime.json. Module UI: /modules/.
What this is not (§1.2)
Not a simple dispatch optimizer. Not a revenue-as-skill leaderboard. Not a fixed morning route planner. Not an autonomous black box that silently overrules humans. Not photo-as-proof of misconduct. Not fuel-first. Not an automatic 30-day callback penalty. Not a PDF portal.
License
Apache License 2.0. See LICENSE.
Available Tools
4 toolstrades_runtime_citeB
Public cite.json for Trades-Runtime. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does state 'Public' and 'Read-only', which usefully imply no authentication and no mutating side effects, but it provides no further behavioral detail such as response type, stability, or any operational caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loads the key facts: resource identity and read-only nature. It contains no filler, though it slightly repeats the tool name ('Trades-Runtime') and could have used the saved space to clarify the resource's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, public, read-only tool, the description covers the essential safety profile and resource, but it does not state what the response will contain or how this tool relates to its siblings. Given no output schema and no annotations, a bit more context about the cite.json content would make the definition fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and the schema description coverage is 100%, so the description does not need to explain parameter semantics. The 'Public ... Read-only' phrasing is consistent with a parameterless fetch operation, and no parameter ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (cite.json) and indicates read-only access, but it lacks an explicit verb such as 'retrieve' or 'fetch' and does not explain what the cite.json contains. This makes the tool's purpose understandable but somewhat vague and only weakly differentiates it from sibling tools like trades_runtime_health or trades_runtime_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus its siblings. The description mentions neither alternative tools nor conditions that would make trades_runtime_cite the appropriate choice, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trades_runtime_healthC
Trades-Runtime giveaway health. Read-only. Does not increment counters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully states 'Read-only' and 'Does not increment counters,' which are important side-effect guarantees. However, it does not clarify what 'health' means, what the tool checks, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and contains no filler, which is appropriate for a parameterless health check. However, the fragmented phrasing 'Trades-Runtime giveaway health' is awkward and could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and no parameter information to lean on, so the description must explain what the tool returns or what 'health' means. It does not, leaving an agent uncertain about the tool's actual behavior and result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema already fully documents the parameter surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Trades-Runtime giveaway health' but lacks an explicit verb or action, so it does not clearly state what the tool does. It mostly restates the tool name and does not distinguish itself from siblings like trades_runtime_stats or trades_runtime_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings, no mention of alternatives, and no exclusions. The only context is 'Read-only' and 'Does not increment counters,' which describe behavior rather than usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trades_runtime_skillC
Agent skill markdown for the public giveaway Worker.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It hints that the tool provides a skill markdown document, but it does not state the return format, whether any side effects occur, whether authentication is needed, or what the agent should expect when invoking it. This is a significant gap for a tool with zero annotation context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and has no wasted words, but it is under-specified to the point of being a fragment. It lacks a clear subject-verb structure and does not convey enough information to justify its brevity. This is closer to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what the tool returns or how it behaves. 'Agent skill markdown for the public giveaway Worker' is too vague to give the agent enough context to know when to call it or what to do with the result. The sibling tool names suggest a family of runtime utilities, but this description does not situate itself among them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. There are no parameter meanings to explain, and the description does not need to compensate for missing schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase—'Agent skill markdown for the public giveaway Worker'—rather than a statement with a verb and resource. It restates the word 'skill' from the tool name and vaguely suggests the tool provides markdown, but it never explicitly says what the tool does, what it returns, or how it differs from the sibling tools (health, stats, cite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus the siblings. There is no mention of alternatives, prerequisites, or scenarios where this tool is appropriate. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trades_runtime_statsA
Honest KV view/download counts with human/bot split. Read-only. Does not increment counters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states 'Read-only' and 'Does not increment counters,' which are important safety guarantees. It does not describe the return format or any error behavior, but for a simple read operation, the core behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action ('Honest KV view/download counts') and then adds essential behavioral qualifiers. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the return data looks like. It does not describe the shape of the counts (e.g., JSON structure, fields, or whether they are aggregated). While the operation is simple, an agent might need to know the output format to process it correctly. This gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. With no parameters to document, the baseline is 4. The description adds nothing about parameters (correctly), as none exist. It effectively compensates for the lack of a schema by providing context on what the tool measures.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's function: 'view/download counts with human/bot split' for a KV store. This clearly distinguishes it from sibling tools (skill, health, cite) which serve different purposes. The verb and resource are concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus its siblings, nor does it state any exclusion conditions. However, the distinct focus on stats/logs implicitly signals it is for retrieving counts rather than for skill execution, health checks, or citation tasks. This is sufficient but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.3.4- First observed
trades_runtime_cite - First observed
trades_runtime_health - First observed
trades_runtime_skill - First observed
trades_runtime_stats
TDQS
Scored across 4 tools
Each tool exposes a distinct concern: skill documentation, health status, usage statistics, and citation data. Health and stats are both read-only, but their descriptions clearly separate service health from view/download counts.
All tools follow the same snake_case prefix pattern: trades_runtime_ followed by a specific noun (skill, health, stats, cite). This is consistent and predictable.
Four tools is a well-scoped set for a runtime information server. Each tool covers a meaningful public-facing aspect without unnecessary bloat.
The server surfaces all expected public runtime concerns: usage instructions, health, statistics, and citation metadata. There are no obvious gaps for the stated read-only purpose.
Related MCP Connectors
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Field workforce scheduling for AI agents. GPS punches, forms, timesheets. No dashboard.
- mcpOAuthcom.crisphive
Field operations on a deterministic solver — run jobs, crews & fleet from Claude or ChatGPT.
Ship production-ready TypeScript code in half the time, at half the cost.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceA TypeScript implementation of the MCP Agent framework, providing tools for building context-aware agents with advanced workflow management, logging, and execution capabilities.18-
- AlicenseNot gradedqualityAmaintenanceTypeScript AI SDK with a built-in MCP client: 58+ MCP servers over 4 transports (stdio, HTTP, SSE, WebSocket), 24+ LLM providers behind one interface, streaming, tool calling, RAG, voice (TTS/STT/realtime), and task scheduling.15,748 npm142MIT
- AlicenseNot gradedqualityBmaintenanceA language-neutral runtime for the SEP-2663 task lifecycle and io.sdar/taskExecution Provider Profile, delegating resource facts and side effects to versioned gRPC/Protobuf adapters. Implemented in strict TypeScript, it provides durable scheduling, recovery, and a full test suite for conformance.1Apache 2.0
- FlicenseNot gradedqualityBmaintenanceA native TypeScript AI orchestration engine and MCP server that coordinates autonomous sub-agents for complex coding tasks using DAG-based parallel execution and multi-agent consensus validation, with a real-time web dashboard.1-