@rubytech/create-maxy-code 0.1.347 → 0.1.349

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:0d3d43e2f324aa4f5ab8b192aecd67c30a96b4610c7226a18e7bfb515ffd5b88
+content-hash: sha256:33a6a5683cd3a9f34b0fcbd1d108c7fe20aece1d7d64ecc6da321ff0a8742f08
 brand: maxy-code
 product-name: Maxy
 ---
@@ -1556,7 +1556,7 @@ Every node also carries a provenance stamp — which agent wrote it, in which se
 
 ## Vertical schemas
 
-On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteDesk boots `schema-construction`, which adds the building-contractor entities — `Job`, `LineItem`, `Valuation`, `Milestone`, `QuoteDocument`, `VariationNote`, `InboundInvoice`, `WhatsAppGroup` — grounded in real builder job folders so a job's quote, valuations, variations, and received supplier and subcontractor invoices all hang off one `Job` node. The default Maxy brand boots no vertical (base graph only).
+On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteDesk boots `schema-construction`, the canonical JobLogic-derived field-service ontology, which adds the service-delivery entities — `Job`, `Customer`, `Site`, `Asset`, `Visit`, `Quote`, `QuoteLine`, `Valuation`, `VariationNote`, `JobCost`, `Part`, `PurchaseOrder`, `Invoice`, `InboundInvoice`, `PpmContract`, `WhatsAppGroup` (with `Engineer` and `Supplier` as additional labels on `Person`/`Organization`) — grounded in real builder job folders so a job's customer, site, quote, valuations, variations, costs, and received supplier invoices all hang off one `Job` node. The default Maxy brand boots no vertical (base graph only).
 
 ## Public-facing summaries for customer-readable subjects
 
@@ -1880,6 +1880,39 @@ A QuickBooks connection goes stale if it sits unused for about 100 days, or if y
 
 Switching your Intuit app from sandbox to production requires passing Intuit's own production security review. That is between you and Intuit; it is not something the agent does for you.
 
+---
+# JobLogic
+Source: https://docs.getmaxy.com/joblogic.md
+
+# JobLogic
+
+Connect JobLogic, the field-service management system, so the agent can read and update your jobs end to end — customers, sites, jobs, engineers, visits, quotes, invoices, assets, and timesheets — over JobLogic's REST API.
+
+This connector is built for one team that already runs JobLogic as its system of record. Your field staff send a voice note or message to Maxy from the field; Maxy works out what they mean and makes the JobLogic update for them. Your staff never touch the JobLogic API themselves, so only Maxy's own connection talks to JobLogic.
+
+## What you do once
+
+**1. Ask JobLogic for API access.** Raise a ticket with JobLogic Support for API credentials. Ask for a test (UAT) account first, then production. They give you a client ID, a client secret, and your company tenant id.
+
+**2. Whitelist your connection.** JobLogic only accepts API calls from network addresses you have registered with them. Maxy makes its calls from the machine it runs on, so that machine's public address is the one to register. If the machine moves between networks its address can change, so either run it from one place with a stable address, send its traffic through a fixed address, or ask JobLogic whether production needs this at all. If the address is not registered, calls are refused and the agent will tell you the connection was blocked.
+
+**3. Hand the keys to the agent.** Tell the agent your client ID, secret, tenant id, and whether they are test or production. The agent stores them on your install only and never repeats them back.
+
+## What the agent does after that
+
+Everything else is automatic. The agent keeps the connection alive on its own, refreshing access behind the scenes, and can:
+
+- **Read** anything — "what jobs are open for this site", "show this engineer's visits this week", "list unpaid invoices".
+- **Write** from a field instruction — create or reschedule a visit, log labour and materials against a job, set a job's status, approve a quote, raise an invoice, add a note or a photo to a job.
+
+Because JobLogic's credential belongs to the company rather than to a person, the agent stamps each update with the engineer who reported it. You give the agent a list that maps each staff member's phone number to their JobLogic engineer record once, and it does the rest.
+
+Each create carries a safety key, so if a message is retried or a reply goes missing the same instruction never creates a duplicate record.
+
+## Testing
+
+Do all your testing against the JobLogic test (UAT) environment first. Switch to production only once the test environment behaves the way you expect and your production keys and whitelisting are in place.
+
 ---
 # Calendar and Booking
 Source: https://docs.getmaxy.com/calendar-booking.md
@@ -1898,7 +1931,7 @@ Open `/calendar` on your Maxy address (the same sign-in as the dashboard). It sh
 
 Use **Today** and the arrows to move around, and the view buttons to switch. The calendar reads everything time-bound in your graph: meetings imported from a calendar export or created by a booking, appointments Maxy schedules for you in chat, and tasks that have a due date (shown on their day).
 
-Click any entry to open its details: the full title, time, location, and who is attending, with each attendee on its own line (name, and email beneath it). For a booked meeting you can also edit its title, time, or location, or delete it, and the grid updates straight away. You can **Download** a booked meeting as a calendar file (`.ics`) to add it to Apple, Google, or Outlook calendars; an **Include attendees** toggle next to the button decides whether the file carries the attendee list (off by default). The private note is never written into the downloaded file, since the file can travel outside your admin. In the edit view you can add an attendee (give a name, an email, or both) and remove one; adding someone who is already a contact reuses that contact rather than making a duplicate, and removing them takes them off the meeting but keeps the contact. The edit view also has a private note for that meeting, a place for your own reminders that only you and your team ever see; it never appears on the public booking page or anywhere outside your admin. Appointments Maxy schedules and due-dated tasks are shown for detail only and are changed where they are created, not here. New meetings are still made by a booking or by asking Maxy in chat, not from the calendar.
+Click any entry to open its details: the full title, time, location, and who is attending, with each attendee on its own line (name, and email beneath it). For a booked meeting you can also edit its title, time, or location, or delete it, and the grid updates straight away. You can **Download** a booked meeting as a calendar file (`.ics`) to add it to Apple, Google, or Outlook calendars; when the meeting has attendees, Download asks whether to include them in the file before it saves, and a meeting with no attendees downloads straight away. The private note is never written into the downloaded file, since the file can travel outside your admin. In the edit view you can add an attendee (give a name, an email, or both) and remove one; adding someone who is already a contact reuses that contact rather than making a duplicate, and removing them takes them off the meeting but keeps the contact. The edit view also has a private note for that meeting, a place for your own reminders that only you and your team ever see; it never appears on the public booking page or anywhere outside your admin. Appointments Maxy schedules and due-dated tasks are shown for detail only and are changed where they are created, not here. New meetings are still made by a booking or by asking Maxy in chat, not from the calendar.
 
 Everything on the calendar comes from records the rest of Maxy already uses, scoped to your account.
 

package/payload/platform/plugins/docs/references/calendar-booking.md

@@ -12,7 +12,7 @@ Open `/calendar` on your Maxy address (the same sign-in as the dashboard). It sh
 
 Use **Today** and the arrows to move around, and the view buttons to switch. The calendar reads everything time-bound in your graph: meetings imported from a calendar export or created by a booking, appointments Maxy schedules for you in chat, and tasks that have a due date (shown on their day).
 
-Click any entry to open its details: the full title, time, location, and who is attending, with each attendee on its own line (name, and email beneath it). For a booked meeting you can also edit its title, time, or location, or delete it, and the grid updates straight away. You can **Download** a booked meeting as a calendar file (`.ics`) to add it to Apple, Google, or Outlook calendars; an **Include attendees** toggle next to the button decides whether the file carries the attendee list (off by default). The private note is never written into the downloaded file, since the file can travel outside your admin. In the edit view you can add an attendee (give a name, an email, or both) and remove one; adding someone who is already a contact reuses that contact rather than making a duplicate, and removing them takes them off the meeting but keeps the contact. The edit view also has a private note for that meeting, a place for your own reminders that only you and your team ever see; it never appears on the public booking page or anywhere outside your admin. Appointments Maxy schedules and due-dated tasks are shown for detail only and are changed where they are created, not here. New meetings are still made by a booking or by asking Maxy in chat, not from the calendar.
+Click any entry to open its details: the full title, time, location, and who is attending, with each attendee on its own line (name, and email beneath it). For a booked meeting you can also edit its title, time, or location, or delete it, and the grid updates straight away. You can **Download** a booked meeting as a calendar file (`.ics`) to add it to Apple, Google, or Outlook calendars; when the meeting has attendees, Download asks whether to include them in the file before it saves, and a meeting with no attendees downloads straight away. The private note is never written into the downloaded file, since the file can travel outside your admin. In the edit view you can add an attendee (give a name, an email, or both) and remove one; adding someone who is already a contact reuses that contact rather than making a duplicate, and removing them takes them off the meeting but keeps the contact. The edit view also has a private note for that meeting, a place for your own reminders that only you and your team ever see; it never appears on the public booking page or anywhere outside your admin. Appointments Maxy schedules and due-dated tasks are shown for detail only and are changed where they are created, not here. New meetings are still made by a booking or by asking Maxy in chat, not from the calendar.
 
 Everything on the calendar comes from records the rest of Maxy already uses, scoped to your account.
 

package/payload/platform/plugins/docs/references/joblogic.md

@@ -0,0 +1,28 @@
+# JobLogic
+
+Connect JobLogic, the field-service management system, so the agent can read and update your jobs end to end — customers, sites, jobs, engineers, visits, quotes, invoices, assets, and timesheets — over JobLogic's REST API.
+
+This connector is built for one team that already runs JobLogic as its system of record. Your field staff send a voice note or message to {{productName}} from the field; {{productName}} works out what they mean and makes the JobLogic update for them. Your staff never touch the JobLogic API themselves, so only {{productName}}'s own connection talks to JobLogic.
+
+## What you do once
+
+**1. Ask JobLogic for API access.** Raise a ticket with JobLogic Support for API credentials. Ask for a test (UAT) account first, then production. They give you a client ID, a client secret, and your company tenant id.
+
+**2. Whitelist your connection.** JobLogic only accepts API calls from network addresses you have registered with them. {{productName}} makes its calls from the machine it runs on, so that machine's public address is the one to register. If the machine moves between networks its address can change, so either run it from one place with a stable address, send its traffic through a fixed address, or ask JobLogic whether production needs this at all. If the address is not registered, calls are refused and the agent will tell you the connection was blocked.
+
+**3. Hand the keys to the agent.** Tell the agent your client ID, secret, tenant id, and whether they are test or production. The agent stores them on your install only and never repeats them back.
+
+## What the agent does after that
+
+Everything else is automatic. The agent keeps the connection alive on its own, refreshing access behind the scenes, and can:
+
+- **Read** anything — "what jobs are open for this site", "show this engineer's visits this week", "list unpaid invoices".
+- **Write** from a field instruction — create or reschedule a visit, log labour and materials against a job, set a job's status, approve a quote, raise an invoice, add a note or a photo to a job.
+
+Because JobLogic's credential belongs to the company rather than to a person, the agent stamps each update with the engineer who reported it. You give the agent a list that maps each staff member's phone number to their JobLogic engineer record once, and it does the rest.
+
+Each create carries a safety key, so if a message is retried or a reply goes missing the same instruction never creates a duplicate record.
+
+## Testing
+
+Do all your testing against the JobLogic test (UAT) environment first. Switch to production only once the test environment behaves the way you expect and your production keys and whitelisting are in place.

package/payload/platform/plugins/docs/references/memory-guide.md

@@ -144,7 +144,7 @@ Every node also carries a provenance stamp — which agent wrote it, in which se
 
 ## Vertical schemas
 
-On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteDesk boots `schema-construction`, which adds the building-contractor entities — `Job`, `LineItem`, `Valuation`, `Milestone`, `QuoteDocument`, `VariationNote`, `InboundInvoice`, `WhatsAppGroup` — grounded in real builder job folders so a job's quote, valuations, variations, and received supplier and subcontractor invoices all hang off one `Job` node. The default Maxy brand boots no vertical (base graph only).
+On top of the base graph, each brand boots one optional **vertical** — an extra set of entity types tailored to a trade. The vertical is named by `brand.json#vertical` and defined in a `schema-<name>.md` reference; the memory plugin loads it at startup and validates every write against base + the active vertical. Real Agent boots `schema-estate-agent` (Listing, Property, Viewing, Offer). SiteDesk boots `schema-construction`, the canonical JobLogic-derived field-service ontology, which adds the service-delivery entities — `Job`, `Customer`, `Site`, `Asset`, `Visit`, `Quote`, `QuoteLine`, `Valuation`, `VariationNote`, `JobCost`, `Part`, `PurchaseOrder`, `Invoice`, `InboundInvoice`, `PpmContract`, `WhatsAppGroup` (with `Engineer` and `Supplier` as additional labels on `Person`/`Organization`) — grounded in real builder job folders so a job's customer, site, quote, valuations, variations, costs, and received supplier invoices all hang off one `Job` node. The default Maxy brand boots no vertical (base graph only).
 
 ## Public-facing summaries for customer-readable subjects
 

package/payload/platform/plugins/joblogic/.claude-plugin/plugin.json

@@ -0,0 +1,21 @@
+{
+  "name": "joblogic",
+  "description": "JobLogic field-service connector (bespoke, one account) — OAuth client_credentials, tenant-scoped read/write across the job lifecycle.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "joblogic": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/lib/mcp-spawn-tee/index.js",
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/index.js"
+      ],
+      "env": {
+        "MCP_SPAWN_TEE_NAME": "joblogic"
+      }
+    }
+  }
+}

package/payload/platform/plugins/joblogic/PLUGIN.md

@@ -0,0 +1,182 @@
+---
+name: joblogic
+description: "JobLogic field-service connector (bespoke, one account) — OAuth client_credentials, tenant-scoped read/write across the job lifecycle."
+tools:
+  - name: joblogic-credentials-set
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-connection-status
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-engineer-map-set
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-engineer-map-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-customer-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-customer-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-customer-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-customer-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-site-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-site-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-site-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-site-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-set-status
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-job-approve
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-engineer-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-engineer-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-search-planner
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-deploy
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-visit-cancel
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-quote-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-quote-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-quote-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-quote-approve
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-invoice-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-invoice-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-invoice-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-invoice-payment-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-asset-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-asset-get
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-asset-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-asset-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-timesheet-list
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-timesheet-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-timesheet-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-jobcost-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-jobcost-update
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-note-create
+    publicAllowlist: false
+    adminAllowlist: true
+  - name: joblogic-attachment-url-generate
+    publicAllowlist: false
+    adminAllowlist: true
+skills:
+  - skills/joblogic/SKILL.md
+metadata: {"platform":{"optional":true,"pluginKey":"joblogic"}}
+mcp:
+  command: node
+  args:
+    - ${PLATFORM_ROOT}/lib/mcp-spawn-tee/dist/index.js
+    - ${PLATFORM_ROOT}/plugins/joblogic/mcp/dist/index.js
+  env:
+    MCP_SPAWN_TEE_NAME: joblogic
+    LOG_DIR: ${LOG_DIR}
+    PLATFORM_ROOT: ${PLATFORM_ROOT}
+    ACCOUNT_ID: ${ACCOUNT_ID}
+    SESSION_ID: ${SESSION_ID}
+mcp-manifest: auto
+---
+
+# JobLogic
+
+Connects to JobLogic, a cloud field-service management system (REST/JSON, OAuth 2.0). This is a bespoke connector for one account: it ships inert and does nothing on any other install, gated per-account by the account's `enabledPlugins` plus the presence of credentials in that account's secrets file. It is not part of any brand bundle.
+
+The intended use: field staff send a voice note or message to this install; the agent interprets it and makes the JobLogic write. Staff never call the API themselves, so only this install's outbound IP touches JobLogic.
+
+## Capabilities
+
+- **joblogic-credentials-set** — store the OAuth client_credentials (client id + secret), company tenant id, and environment (uat or production).
+- **joblogic-connection-status** — acquire a token and confirm the environment, tenant, and source-IP whitelisting work.
+- **joblogic-engineer-map-set / -list** — map sender phone numbers to JobLogic engineer ids for write attribution.
+- **Reads** — list/get/search across customers, sites, jobs, engineers, visits (planner), quotes, invoices, assets, and timesheets.
+- **Writes** — create and update those records, plus lifecycle transitions: set a job status, approve a job or quote, deploy or cancel a visit, log job-cost lines, raise an invoice, record a payment, add a note or generate an attachment upload URL.
+
+## Authorization and idempotency
+
+A write is authorized by the person who messaged the install requesting it; the agent does not add a second confirmation step. Every create takes an idempotency key, so a retry or a lost response never creates a duplicate record.
+
+## Setup
+
+Connecting JobLogic runs through the `joblogic` skill (`skills/joblogic/SKILL.md`): the operator raises a JobLogic Support ticket, whitelists the install's outbound IP, and hands over the credentials. Use UAT for all testing before switching to production.
+
+## Credentials and isolation
+
+Credentials live only in this account's secrets directory (`secrets/joblogic.json`, mode `0600`), inside the brand-isolated install. The bearer token is acquired on demand from the client credentials and refreshed automatically before it expires.
+

package/payload/platform/plugins/joblogic/lib/mcp-spawn-tee/index.js

@@ -0,0 +1,193 @@
+#!/usr/bin/env node
+"use strict";
+/**
+ * MCP spawn-tee — in-process stderr capture + lifecycle observability.
+ *
+ * Claude Code spawns each MCP server itself; the platform never holds a
+ * ChildProcess handle. This shim sits between Claude Code and the real MCP
+ * server: Claude Code runs `node <this> <real-entry>`, and the shim runs the
+ * real entry IN ITS OWN PROCESS via dynamic import() — one node runtime, not
+ * two. Before importing, it replaces process.stderr.write with a tee so every
+ * stderr byte the server writes is mirrored to the log sinks; stdin and stdout
+ * (the JSON-RPC channel) are never touched.
+ *
+ *   Claude Code CLI → shim (this file) = node running <real-entry> in-process
+ *        stdin/stdout : untouched (JSON-RPC channel)
+ *        stderr       : process.stderr.write teed → per-date + per-session + passthrough
+ *
+ * Destinations (Task 706) — unchanged:
+ *   - `${LOG_DIR}/mcp-<name>-stderr-<date>.log`  — per-date raw (back-compat;
+ *     the in-process mcp-stderr-tee and the [mcp-init-error] probe read it).
+ *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — per-session raw + lifecycle
+ *     lines. Authoritative sink. Absent when SESSION_ID is unset (enumeration
+ *     spawn) — then the per-date file is the fallback.
+ *   - `server.log` via the loopback log-ingest route — best-effort mirror of
+ *     the [mcp-helper] lifecycle lines.
+ *
+ * Lifecycle lines, correlation key `session=<id8> server=<name>` — unchanged:
+ *   [mcp-helper] op=spawn ... pid= entry=
+ *   [mcp-helper] op=boot  ... head=<first stderr bytes>
+ *   [mcp-helper] op=exit  ... code= signal= lifetimeMs= stderr-tail=
+ *
+ * Process model (Task 989): the shim IS the server's process. op=exit fires
+ * from process.on("exit"), so it covers a normal exit, a non-zero exit, an
+ * uncaught throw (code 1), and a catchable-signal exit (SIGTERM/SIGINT/SIGHUP,
+ * whose handlers record the signal name). An external SIGKILL is uncatchable
+ * and leaves no op=exit line — the per-session stderr tail already on disk and
+ * Claude Code's own transport-drop are the evidence for that death mode.
+ *
+ * The shim never writes to fd 1 (stdout) — that is the JSON-RPC channel.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+const node_fs_1 = require("node:fs");
+const node_path_1 = require("node:path");
+const node_url_1 = require("node:url");
+const SERVER_NAME = process.env.MCP_SPAWN_TEE_NAME ?? "unknown";
+const LOG_DIR = process.env.LOG_DIR;
+const SESSION_ID = process.env.SESSION_ID;
+const PLATFORM_PORT = process.env.PLATFORM_PORT;
+const ENTRY = process.argv[2];
+const SESSION_ID8 = SESSION_ID ? SESSION_ID.slice(0, 8) : "—";
+const spawnStamp = Date.now();
+// Per-session raw + lifecycle log (Task 706). Empty SESSION_ID (enumeration
+// spawn) → undefined, and the per-date file is the fallback.
+const perSessionPath = LOG_DIR && SESSION_ID
+    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-${SESSION_ID}.log`)
+    : undefined;
+const perDatePath = LOG_DIR
+    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-stderr-${new Date(spawnStamp).toISOString().slice(0, 10)}.log`)
+    : undefined;
+// Rolling tail of entry stderr for op=exit. Capped so a chatty server cannot
+// grow the buffer without bound.
+const TAIL_CAP = 2048;
+let stderrTail = "";
+let bootEmitted = false;
+let exitEmitted = false;
+let exitSignal;
+// The real stderr writer, captured before the tee replaces it. Lifecycle lines
+// and stderr passthrough both go through this so they are never re-teed into
+// the per-date sink nor recursed back into the patched writer.
+const rawStderrWrite = process.stderr.write.bind(process.stderr);
+// LOG_DIR is created once, lazily, on the first successful append — not per
+// chunk. teeWrite runs on the server's own stderr hot path now, so a per-call
+// mkdirSync would be two syscalls per log line for nothing.
+let logDirReady = false;
+function appendSafe(path, data) {
+    if (!path || !LOG_DIR)
+        return;
+    try {
+        if (!logDirReady) {
+            (0, node_fs_1.mkdirSync)(LOG_DIR, { recursive: true });
+            logDirReady = true;
+        }
+        (0, node_fs_1.appendFileSync)(path, data);
+    }
+    catch {
+        /* unwritable destination — never mask primary output */
+    }
+}
+// Best-effort mirror of a lifecycle line to server.log via the loopback
+// log-ingest route. Fire-and-forget: the per-session file is authoritative, so
+// a dropped POST loses nothing. On the "exit" event the loop is stopping, so
+// the op=exit mirror may not flush — the per-session line, written sync, holds.
+function postToServerLog(suffix, level) {
+    if (!PLATFORM_PORT)
+        return;
+    try {
+        const ctrl = new AbortController();
+        const t = setTimeout(() => ctrl.abort(), 500);
+        t.unref?.(); // never let the abort timer keep the shim's event loop alive
+        void fetch(`http://127.0.0.1:${PLATFORM_PORT}/api/admin/log-ingest`, {
+            method: "POST",
+            headers: { "content-type": "application/json" },
+            body: JSON.stringify({ tag: "mcp-helper", level, line: suffix }),
+            signal: ctrl.signal,
+        }).then(() => clearTimeout(t)).catch(() => clearTimeout(t));
+    }
+    catch {
+        /* fetch threw synchronously — best-effort only */
+    }
+}
+// Emit one [mcp-helper] lifecycle line: authoritative per-session file (sync,
+// survives process.exit), the shim's own stderr via the RAW writer (journald /
+// Claude Code visibility, never re-teed), and a best-effort server.log mirror.
+// `suffix` is the line body after the tag and carries no newline (the
+// log-ingest route rejects newlines).
+function emitLifecycle(suffix, level) {
+    const line = `[mcp-helper] ${suffix}\n`;
+    appendSafe(perSessionPath, line);
+    try {
+        rawStderrWrite(line);
+    }
+    catch { /* stderr closed */ }
+    postToServerLog(suffix, level);
+}
+if (!ENTRY) {
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason="no entry given (argv[2] missing)"`, "error");
+    process.exit(2);
+}
+// Replace process.stderr.write with a tee: mirror every server stderr byte to
+// the per-date and per-session sinks, keep a rolling tail for op=exit, emit
+// op=boot on the first bytes, then pass the write through to the real stderr.
+const teeWrite = ((...args) => {
+    const chunk = args[0];
+    appendSafe(perDatePath, chunk); // per-date raw (back-compat)
+    appendSafe(perSessionPath, chunk); // per-session raw (Task 706)
+    const text = typeof chunk === "string" ? chunk : Buffer.from(chunk).toString("utf8");
+    stderrTail = (stderrTail + text).slice(-TAIL_CAP);
+    if (!bootEmitted) {
+        bootEmitted = true;
+        const head = text.split("\n")[0].slice(0, 200);
+        emitLifecycle(`op=boot session=${SESSION_ID8} server=${SERVER_NAME} head=${JSON.stringify(head)}`, "info");
+    }
+    return rawStderrWrite(...args); // passthrough
+});
+process.stderr.write = teeWrite;
+// Catchable-signal handling. The shim drives the exit ONLY when it is the sole
+// listener for the signal — i.e. the imported entry installed no handler of its
+// own. In that case it records the signal (so op=exit carries signal=<sig>) and
+// exits with 128+signum, mirroring the prior wrapper's exit-status convention.
+//
+// When the entry DID install a handler, the shim defers entirely and records
+// nothing: the entry's handler decides the exit code, and op=exit reflects that
+// exit verbatim. This matches the prior two-process model, where a child that
+// caught the signal and exited cleanly was observed as code=0 signal=— (a clean
+// self-exit), not as a signal death. Setting exitSignal here unconditionally
+// would mislabel every graceful signal-driven shutdown as a signal kill.
+function onSignal(sig, code) {
+    return () => {
+        if (process.listenerCount(sig) === 1) {
+            exitSignal = sig;
+            process.exit(code);
+        }
+    };
+}
+process.on("SIGTERM", onSignal("SIGTERM", 143));
+process.on("SIGINT", onSignal("SIGINT", 130));
+process.on("SIGHUP", onSignal("SIGHUP", 129));
+// op=exit, emitted once from the process "exit" event. Sync-only — the loop is
+// stopping. When a catchable signal caused the exit, report code=— signal=<sig>
+// to match the prior wrapper's format; otherwise code=<exit code> signal=—.
+process.on("exit", (code) => {
+    if (exitEmitted)
+        return;
+    exitEmitted = true;
+    const lifetimeMs = Date.now() - spawnStamp;
+    const tail = stderrTail.slice(-200);
+    const codeField = exitSignal ? "—" : String(code);
+    const level = exitSignal || code !== 0 ? "error" : "info";
+    emitLifecycle(`op=exit session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} ` +
+        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
+});
+emitLifecycle(`op=spawn session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} entry=${ENTRY}`, "info");
+// Run the real MCP server in THIS process. Dynamic import() (not top-level
+// await — this file compiles to CommonJS) loads the ESM entry; a load-time
+// failure mirrors the old child spawn-error path (op=error, exit 127). The
+// op=exit handler is suppressed on this path so op=error stays the sole record.
+import((0, node_url_1.pathToFileURL)(ENTRY).href).catch((err) => {
+    const msg = err instanceof Error ? err.message : String(err);
+    exitEmitted = true;
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${msg}`)}`, "error");
+    process.exit(127);
+});
+//# sourceMappingURL=index.js.map

package/payload/platform/plugins/joblogic/lib/mcp-spawn-tee/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "commonjs"
+}

package/payload/platform/plugins/joblogic/mcp/dist/index.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=index.d.ts.map

package/payload/platform/plugins/joblogic/mcp/dist/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":""}