Loomworks induction solution — candidate seed drafting handoff v0.1

Version. 0.1 Date. 2026-04-24 Status. Handoff into a fresh chat for candidate seed drafting. Three engagements entering Loomworks: PartsPilot, FieldPilot, the Agricultural Engagement. PartsPilot first.

What this hands off

Candidate seed drafting for three engagements entering Loomworks. This is the induction solution named in the Loomworks candidate seed v0.3 — a separate one-off solution deriving seeds from prior material. The induction solution is not part of Loomworks and is not a Loomworks phase.

Each engagement gets a candidate seed per R-A5 through R-A11. The seeds enter the normal seed-induction loop once drafted. Order: PartsPilot first (most documented, clearest boundary), FieldPilot second (same architectural DNA), Agricultural Engagement third (references both).

What to read first, in order

1. current-status-manifest-v0_9.md — the orientation artifact. Absorbs Phase 12 landing. Names the induction solution as queued work.

1. loomworks-candidate-seed-v0_3.md — Loomworks' own seed. The structural template for what a candidate seed looks like. Section "Success conditions" names Enrollium, ExpenseDesk, and FarmGuard as engagements entering Loomworks; the scope has since narrowed to three agricultural-programme engagements (PartsPilot, FieldPilot, the Agricultural Engagement) going first.

1. what-dunin7-is-building-v0_17.docx — the methodology document. R-A5 through R-A11 define what a seed must carry.

Three engagements — why three, not one

The FarmGuard programme is a layered architecture: FORAY (protocol) → PartsPilot (buying-side platform) → FieldPilot (service-side platform) → Agricultural Engagement (domain layer) → FarmGuard (branded farmer-facing instance). These were originally counted as one engagement ("FarmGuard") entering Loomworks.

In the scoping session (2026-04-24), the Operator and Claude worked through three readings: (A) FarmGuard the branded product as one engagement, (B) the Agricultural Engagement as one engagement with FarmGuard as a declared render-type, (C) the programme as multiple engagements. Reading B was explored first — the Agricultural Engagement as the single engagement, with PartsPilot and FieldPilot patterns entering as assertions.

Claude then raised the question: is it better to look at three engagements that are aware of each other, or one? The argument for three:

• PartsPilot's PPO model serves industrial parts supply, not just agriculture. Locking its knowledge inside an agricultural engagement means the day PartsPilot serves a non-agricultural vertical, that knowledge is behind the wrong boundary.
• Same for FieldPilot — a sheep shearer's booking and a plumber's service call use the same job lifecycle.
• Platform knowledge is domain-agnostic. Agricultural knowledge is domain-specific. They belong in different memories.
• "Aware of each other" is the load-bearing phrase: the Agricultural Engagement's seed references PartsPilot and FieldPilot by name. When PartsPilot's memory accumulates a refinement, the Agricultural Engagement's Operator can see that upstream knowledge has changed.

The Operator confirmed three engagements. Enrollium and ExpenseDesk wait.

PartsPilot — source material for the candidate seed

PartsPilot is the most developed of the three and goes first. The source material is:

From the PartsPilot project (Phase 1 era)

• PARTSPILOT_DISCOVERY_RECORD-v0_1.docx — produced 2026-04-24 from the Phase 1 PartsPilot project. Carries the origin story (Brooklyn supply house), the PPO workflow rationale, the full document inventory (DACO_Project_Specification v1.0.0, PP-SPEC-PRICING v1.2.0, PP-SPEC-TENANT v1.2.0, GTM materials, competitive analyses), decision trajectories (PPO vs direct checkout, Customer ID vs email auth, pluggable pricing engine, phase-plans-written-just-before-execution, DCKAP over direct ERP integration, cross-catalog aggregation as structural moat). State at time of document: Phase 1 complete (160 tests), Phase 2 planned.

From the PartsPilot project (Phase 2+ era)

• PARTSPILOT_PHASE2_DISCOVERY_RECORD_V0_1.md — produced 2026-04-24 from the later PartsPilot project. Carries the current state: Phases 1–4 complete at 604 tests (tag v0.4.0, commit 8c7cd5a). Documents: HANDOFF_V1_27_0.md (final Phase 4), Phase 2 and Phase 4 plans, APPLICATION_STANDARDS, TESTING_STANDARDS, docs/PHASE4_SUMMARY.md. Settled commitments: technology stack, authentication model, multi-tenancy, four-tier hierarchy, pricing engine architecture, test isolation, audit logging, configuration cascade, commit conventions. Phase 5 scoped (P5-01 through P5-13: search, shopping cart, order management, webhooks, data export) but not started. Deferred: FORAY integration (Phase 6), Gemini multimodal, ERP SOAP.

From the GitHub repo

• README.md at https://github.com/DUNIN7/PartsPilot — comprehensive current-state summary. Phase 1 through Phase 4 features. 604 tests. Tech stack. Project structure. Authentication model. Multi-tenant architecture. API overview.
• HANDOFF_V1_14_0.md — one of the handoff documents in the repo. Carries detailed code-level reference: auth patterns, file writing protocol, key source files, pricing architecture, ERP integration, Phase 4 task summaries. Note: the repo contains handoffs from v1.4.0 through v1.14.0; the latest (v1.27.0) is in dunin7-docs/partspilot/ per the Phase 2 discovery record.

From the FarmGuard programme discovery record

• farmguard-discovery-record-v0_2.md — Section 3.2 (PartsPilot → Agricultural Engagement buying-side mapping), Section 4.2 (what's built in PartsPilot), Section 4.4 (settled principles). This document is the source for how PartsPilot connects to the Agricultural Engagement — the PPO model applied to agricultural parts counter culture.

What the seed needs to capture

• What the work is. Buying-side commerce infrastructure — the PPO model, the pricing engine, the white-label multi-tenant architecture, the ERP adapter pattern. Domain-agnostic platform; agriculture is one vertical among many.
• Who consumes the work. Parts distributors and their customers (primary). Partner resellers and buying groups (secondary). The Agricultural Engagement (downstream consumer referencing PartsPilot patterns). Future implementers or integrators.
• Voice. Operator-first, AI-as-production-layer, per DUNIN7 convention.
• Constraints. Technology stack (Next.js 15, PostgreSQL, Drizzle, TypeScript strict). Authentication model (username-only, no email). Multi-tenancy (tenant isolation structural). PPO workflow (non-negotiable). Test discipline (factory pattern, zero failures). Configuration cascade (platform → partner → tenant).
• Success conditions. A parts distributor can deploy a branded portal, configure pricing, manage customers, and process PPOs through the platform without understanding the infrastructure. Shopping cart and order management (Phase 5) are the next operational milestone.
• Declared render-types. What PartsPilot-the-engagement produces as artifacts — handoff documents, phase plans, API documentation, deployment guides, phase summaries, discovery records. The engagement has been producing these throughout its construction, paralleling Loomworks' own recursion.

FieldPilot — source material available

• farmguard-discovery-record-v0_2.md — Section 2.2 (FieldPilot spec at v0.3.2), Section 3.3 (FieldPilot → Agricultural Engagement services mapping), Section 4.3 (what's specified). Comprehensive spec covering 19 sections.
• FieldPilot spec v0.3.2 — referenced in the discovery record but not uploaded to this project. The Operator may need to upload it or have the FieldPilot project produce a discovery record.
• HANDOFF_V1_0_0.md (FieldPilot) — in dunin7-docs/fieldpilot/ per the Phase 2 discovery record.

FieldPilot is at specification stage, not built codebase. The seed reflects that maturity — commitments at the spec level, not at the code-proven level.

Agricultural Engagement — source material available

• farmguard-discovery-record-v0_2.md — the primary source. Sections 1, 3, 4.4, 4.5, 4.6 (programme architecture, settled principles, settled design, FarmGuard product decisions).
• Agricultural Engagement Requirements v0.7 — referenced but not uploaded. Sections 1–4 written (Framing, Participants, Principles, Buying-Side Environment). Sections 5–8 not yet drafted. This is the upstream domain requirements document.
• FarmGuard AI Specification v3.1 — referenced but not uploaded. ~1,300+ paragraphs. The richest source of domain assertions, but requires sorting into engagement-level vs FarmGuard-specific knowledge.
• FarmGuard Shortform Requirements Spec v0.1 — in Loomworks project knowledge (loomworks-candidate-seed-v0_3.md references it indirectly).

The Agricultural Engagement seed references PartsPilot and FieldPilot by name as upstream platforms whose patterns it applies to the agricultural domain. FarmGuard is a declared render-type — the farmer-facing branded instance.

Project knowledge updates before the next chat

• Add current-status-manifest-v0_9.md (replacing v0_8)
• Add this handoff document
• Add PARTSPILOT_DISCOVERY_RECORD-v0_1.docx
• Add PARTSPILOT_PHASE2_DISCOVERY_RECORD_V0_1.md
• Add farmguard-discovery-record-v0_2.md
• Consider uploading: FieldPilot spec v0.3.2, Agricultural Engagement Requirements v0.7, FarmGuard AI Specification v3.1 (or ask each project to produce discovery records)

Operator preferences in play

• Versioned filenames with version in title and header.
• Produce .md only from Claude.ai; CC handles .docx if needed.
• Discovery-record posture.
• Plain-English with Operators.
• One engagement at a time. PartsPilot first.
• "Too much will break me" — scope each seed drafting session tightly. Don't attempt all three in one sitting.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks induction solution — candidate seed drafting handoff — v0.1 — 2026-04-24