> For the complete documentation index, see [llms.txt](https://t420.gitbook.io/t420/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://t420.gitbook.io/t420/claude-shadow-layer-kickoff.md). # Claude Kickoff Prompt — Shadow Training Layer > **Status: EXECUTED** — Shadow training layer v1 implemented as of 2026-04-04. Migration `029_shadow_training_layer.sql` created, 6 shadow services built, instrumentation wired into `RequestWorkflowService`. Retained as historical context. Paste this into a fresh Claude Code terminal session at the FleetOS repo root. *** You are working in the `ZBO19/FleetOS` repository. Start by reading these files in this order: 1. `docs/shadow-training-layer.md` 2. `docs/shadow-training-schema-plan.md` 3. `docs/agent.md` 4. `docs/production-plan.md` Your mission: Implement **v1 of the FleetOS shadow training layer** in Supabase/Postgres and wire the first instrumentation points into the current request workflow. This layer is for: * observing real coordination workflows * capturing decision points, candidate actions, selected actions, outcomes, and state snapshots * generating training-quality data for future autonomous coordination agents * running in **shadow mode first** It is **not** for unsafe autonomy. It is **not** for replacing the current workflow. It is **not** a research note. It must become a real buildable layer. ## Non-negotiables * Do not break current FleetOS workflow behavior. * Keep this layer server-written / service-role oriented first. * Do not expose unsafe direct client writes to shadow tables. * Preserve compatibility with existing `service_requests`-based workflow. * Keep changes incremental and strongly typed. * Prefer practical v1 instrumentation over overbuilding an ML platform. ## What to build ### Phase 1 — database layer Using `docs/shadow-training-schema-plan.md`, create Supabase/Postgres migrations for: * enums * `coordination_sessions` * `workflow_events` * `state_snapshots` * `decision_points` * `candidate_actions` * `selected_actions` * `outcome_records` * `outcome_record_decision_points` * `training_examples` * indexes * initial RLS posture ### Phase 2 — service layer Create services such as: * `services/shadow/CoordinationSessionService.ts` * `services/shadow/WorkflowEventService.ts` * `services/shadow/DecisionPointService.ts` * `services/shadow/OutcomeService.ts` * `services/shadow/TrainingExampleService.ts` ### Phase 3 — instrumentation Wire the first instrumentation points into the current request workflow for: 1. request created 2. quote submitted / supplier responded 3. quote approved or declined 4. technician assigned 5. bay assigned 6. work completed At each point, create the appropriate combination of: * workflow events * state snapshots * decision points * selected actions * outcome records ### Phase 4 — backfill plan Prepare but do not overbuild a backfill path for existing service request history. ## How to work ### Step 1 Read and summarize the four docs above in your own words. ### Step 2 Inspect the current repo for: * Supabase migration patterns * current schema conventions * service layer conventions * existing request workflow entry points * the best integration points for instrumentation ### Step 3 Produce a concrete execution plan with: * new migrations to add * new service files to add * existing files that must be touched * compatibility risks * RLS considerations ### Step 4 Implement the migrations first. ### Step 5 Implement the shadow services. ### Step 6 Instrument the current request workflow in the narrowest safe way. ## Guardrails * Shadow mode first. * No autonomous action-taking. * No broad public write access. * No giant speculative ML infrastructure. * Prefer typed columns for stable concepts and JSONB only where it adds flexibility. ## Output style * Be concrete. * Show exact files changed. * Keep a running checklist. * Make incremental commits. * Call out migration risks before applying schema changes. * Avoid philosophical discussion. ## First response format Your first response should contain exactly these sections: 1. `What I read` 2. `What the repo appears to do today` 3. `Best integration points for shadow instrumentation` 4. `Migration and service plan` 5. `First code changes I will make` Then start work. *** ## Shorter version If you want a shorter kickoff, use this: Read: * `docs/shadow-training-layer.md` * `docs/shadow-training-schema-plan.md` * `docs/agent.md` * `docs/production-plan.md` Then: 1. inspect current Supabase schema and request workflow 2. propose migrations + services + instrumentation plan 3. implement the shadow training schema in Supabase migrations 4. add shadow services 5. instrument request lifecycle events in the narrowest safe way Do not break current workflow. Keep it server-written and shadow-only. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://t420.gitbook.io/t420/claude-shadow-layer-kickoff.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.