@syntesseraai/opencode-feature-factory 0.10.2 → 0.10.4

package/dist/workflow/fan-out.d.ts

@@ -18,6 +18,9 @@ import type { NamedModel, ModelId } from './types.js';
 export type Client = {
     session: {
         create(options: {
+            query?: {
+                directory?: string;
+            };
             body?: {
                 parentID?: string;
                 title?: string;
@@ -28,6 +31,9 @@ export type Client = {
             };
         }>;
         prompt(options: {
+            query?: {
+                directory?: string;
+            };
             path: {
                 id: string;
             };
@@ -53,6 +59,9 @@ export type Client = {
             };
         }>;
         promptAsync(options: {
+            query?: {
+                directory?: string;
+            };
             path: {
                 id: string;
             };
@@ -100,6 +109,14 @@ export declare function extractText(parts: Array<{
     text?: string;
     [k: string]: unknown;
 }>): string;
+export interface SessionContext {
+    sessionId: string;
+    directory?: string;
+}
+export declare function createRunParentSession(client: Client, callerSessionId: string, options?: {
+    title?: string;
+    directory?: string;
+}): Promise<SessionContext>;
 export interface FanOutResult {
     tag: string;
     raw: string;
@@ -111,13 +128,13 @@ export interface FanOutResult {
  * Each model's work runs in its own child session so none of the
  * intermediate outputs pollute the parent context window.
  */
-export declare function fanOut(client: Client, parentSessionId: string, models: readonly NamedModel[], buildPrompt: (tag: string) => string, agent?: string): Promise<FanOutResult[]>;
+export declare function fanOut(client: Client, context: SessionContext, models: readonly NamedModel[], buildPrompt: (tag: string) => string, agent?: string): Promise<FanOutResult[]>;
 /**
  * Prompt in an isolated child session and return the raw text response.
  *
  * This keeps the sub-step off the parent's context window.
  */
-export declare function promptSession(client: Client, parentSessionId: string, prompt: string, options?: {
+export declare function promptSession(client: Client, context: SessionContext, prompt: string, options?: {
     model?: ModelId;
     agent?: string;
     title?: string;
@@ -131,6 +148,6 @@ export declare function promptSession(client: Client, parentSessionId: string, p
  *
  * Errors are swallowed — notification delivery must never break the pipeline.
  */
-export declare function notifyParent(client: Client, sessionId: string, agent: string | undefined, message: string, options?: {
+export declare function notifyParent(client: Client, context: SessionContext, agent: string | undefined, message: string, options?: {
     noReply?: boolean;
 }): Promise<void>;

package/dist/workflow/fan-out.js

@@ -19,6 +19,29 @@ export function extractText(parts) {
         .map((p) => p.text)
         .join('\n');
 }
+function withDirectory(directory) {
+    if (!directory) {
+        return undefined;
+    }
+    return { directory };
+}
+export async function createRunParentSession(client, callerSessionId, options) {
+    const session = await client.session.create({
+        query: withDirectory(options?.directory),
+        body: {
+            parentID: callerSessionId,
+            title: options?.title,
+        },
+    });
+    const runParentId = session.data?.id;
+    if (!runParentId) {
+        throw new Error('Failed to create run parent session');
+    }
+    return {
+        sessionId: runParentId,
+        directory: options?.directory,
+    };
+}
 // ---------------------------------------------------------------------------
 // Isolated session helper
 // ---------------------------------------------------------------------------
@@ -28,11 +51,12 @@ export function extractText(parts) {
  * The child session is parented to `parentSessionId` so it appears in the
  * session tree but its messages do **not** pollute the parent context window.
  */
-async function promptInChildSession(client, parentSessionId, prompt, options) {
+async function promptInChildSession(client, context, prompt, options) {
     // 1. Create an isolated child session
     const session = await client.session.create({
+        query: withDirectory(context.directory),
         body: {
-            parentID: parentSessionId,
+            parentID: context.sessionId,
             title: options?.title,
         },
     });
@@ -53,6 +77,7 @@ async function promptInChildSession(client, parentSessionId, prompt, options) {
         body.agent = options.agent;
     }
     const response = await client.session.prompt({
+        query: withDirectory(context.directory),
         path: { id: childId },
         body,
     });
@@ -66,9 +91,9 @@ async function promptInChildSession(client, parentSessionId, prompt, options) {
  * Each model's work runs in its own child session so none of the
  * intermediate outputs pollute the parent context window.
  */
-export async function fanOut(client, parentSessionId, models, buildPrompt, agent) {
+export async function fanOut(client, context, models, buildPrompt, agent) {
     const results = await Promise.all(models.map(async (nm) => {
-        const raw = await promptInChildSession(client, parentSessionId, buildPrompt(nm.tag), {
+        const raw = await promptInChildSession(client, context, buildPrompt(nm.tag), {
             model: nm.model,
             agent,
             title: `ff-fanout-${nm.tag}`,
@@ -85,8 +110,8 @@ export async function fanOut(client, parentSessionId, models, buildPrompt, agent
  *
  * This keeps the sub-step off the parent's context window.
  */
-export async function promptSession(client, parentSessionId, prompt, options) {
-    return promptInChildSession(client, parentSessionId, prompt, options);
+export async function promptSession(client, context, prompt, options) {
+    return promptInChildSession(client, context, prompt, options);
 }
 // ---------------------------------------------------------------------------
 // Parent session notification helper
@@ -100,7 +125,7 @@ export async function promptSession(client, parentSessionId, prompt, options) {
  *
  * Errors are swallowed — notification delivery must never break the pipeline.
  */
-export async function notifyParent(client, sessionId, agent, message, options) {
+export async function notifyParent(client, context, agent, message, options) {
     try {
         const body = {
             noReply: options?.noReply ?? true,
@@ -110,7 +135,8 @@ export async function notifyParent(client, sessionId, agent, message, options) {
             body.agent = agent;
         }
         await client.session.promptAsync({
-            path: { id: sessionId },
+            query: withDirectory(context.directory),
+            path: { id: context.sessionId },
             body,
         });
     }

package/dist/workflow/orchestrator.d.ts

@@ -4,7 +4,7 @@
  * Re-exports the fan-out, gate, and type modules as a single convenient
  * entry-point for tool implementations.
  */
-export { fanOut, promptSession, extractText, notifyParent, type Client } from './fan-out.js';
+export { fanOut, promptSession, extractText, notifyParent, createRunParentSession, type Client, type SessionContext, } from './fan-out.js';
 export { evaluatePlanningGate, evaluateReviewGate, evaluateDocGate, evaluateMiniLoopImplGate, evaluateMiniLoopDocGate, } from './gate-evaluator.js';
 export { runCI, ciScriptExists } from './ci-runner.js';
 export * from './types.js';

package/dist/workflow/orchestrator.js

@@ -4,7 +4,7 @@
  * Re-exports the fan-out, gate, and type modules as a single convenient
  * entry-point for tool implementations.
  */
-export { fanOut, promptSession, extractText, notifyParent } from './fan-out.js';
+export { fanOut, promptSession, extractText, notifyParent, createRunParentSession, } from './fan-out.js';
 export { evaluatePlanningGate, evaluateReviewGate, evaluateDocGate, evaluateMiniLoopImplGate, evaluateMiniLoopDocGate, } from './gate-evaluator.js';
 export { runCI, ciScriptExists } from './ci-runner.js';
 export * from './types.js';

package/dist/workflow/run-isolation.d.ts

@@ -0,0 +1,13 @@
+export interface WorktreeOptions {
+    enabled?: boolean;
+    parentDirectory?: string;
+}
+export interface RunDirectoryContext {
+    runId: string;
+    runDirectory: string;
+    worktreeEnabled: boolean;
+    worktreePath?: string;
+    repoRoot?: string;
+}
+export declare function resolveRunDirectory(toolTag: 'pipeline' | 'mini-loop', worktree: WorktreeOptions | undefined, cwd?: string): Promise<RunDirectoryContext>;
+export declare function cleanupWorktree(ctx: RunDirectoryContext): Promise<void>;

package/dist/workflow/run-isolation.js

@@ -0,0 +1,77 @@
+import { mkdir } from 'node:fs/promises';
+import { randomUUID } from 'node:crypto';
+import { basename, isAbsolute, join, resolve } from 'node:path';
+const UNSAFE_WORKTREE_PARENT_DIRS = new Set(['/', '/etc']);
+function assertSafeParentDirectory(parentDirectory) {
+    const normalized = resolve(parentDirectory);
+    if (UNSAFE_WORKTREE_PARENT_DIRS.has(normalized)) {
+        throw new Error(`Unsafe worktree_parent_dir: ${parentDirectory}. Choose a dedicated writable path.`);
+    }
+}
+function resolveParentDirectory(cwd, parentDirectory) {
+    // Trust model: worktree_parent_dir is caller-controlled and can point anywhere
+    // on the local filesystem. We allow flexible absolute/relative paths but reject
+    // obviously unsafe system locations where accidental cleanup would be dangerous.
+    if (!parentDirectory || parentDirectory.trim().length === 0) {
+        return join(cwd, '.feature-factory', 'worktrees');
+    }
+    const resolvedParent = isAbsolute(parentDirectory)
+        ? parentDirectory
+        : resolve(cwd, parentDirectory);
+    assertSafeParentDirectory(resolvedParent);
+    return resolvedParent;
+}
+async function runGit(args, cwd) {
+    // eslint-disable-next-line no-undef
+    const proc = Bun.spawn(['git', ...args], {
+        cwd,
+        stdout: 'pipe',
+        stderr: 'pipe',
+    });
+    const [stdout, stderr] = await Promise.all([
+        new Response(proc.stdout).text(),
+        new Response(proc.stderr).text(),
+        proc.exited,
+    ]);
+    if (proc.exitCode !== 0) {
+        const detail = stderr.trim() || stdout.trim() || `git ${args.join(' ')} failed`;
+        throw new Error(detail);
+    }
+    return stdout.trim();
+}
+export async function resolveRunDirectory(toolTag, worktree, cwd = process.cwd()) {
+    const runId = `${toolTag}-${Date.now()}-${randomUUID().slice(0, 8)}`;
+    if (!worktree?.enabled) {
+        return {
+            runId,
+            runDirectory: cwd,
+            worktreeEnabled: false,
+        };
+    }
+    const repoRoot = await runGit(['rev-parse', '--show-toplevel'], cwd);
+    const head = await runGit(['rev-parse', '--verify', 'HEAD'], repoRoot);
+    const parentDirectory = resolveParentDirectory(repoRoot, worktree.parentDirectory);
+    await mkdir(parentDirectory, { recursive: true });
+    const repoName = basename(repoRoot);
+    const worktreePath = join(parentDirectory, `${repoName}-${runId}`);
+    await runGit(['worktree', 'add', '--detach', worktreePath, head], repoRoot);
+    return {
+        runId,
+        runDirectory: worktreePath,
+        worktreeEnabled: true,
+        worktreePath,
+        repoRoot,
+    };
+}
+export async function cleanupWorktree(ctx) {
+    if (!ctx.worktreeEnabled || !ctx.worktreePath) {
+        return;
+    }
+    const gitCwd = ctx.repoRoot ?? ctx.runDirectory;
+    try {
+        await runGit(['worktree', 'remove', '--force', ctx.worktreePath], gitCwd);
+    }
+    catch (error) {
+        console.warn('[feature-factory] Failed to cleanup run worktree:', error);
+    }
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "@syntesseraai/opencode-feature-factory",
-  "version": "0.10.2",
+  "version": "0.10.4",
   "type": "module",
   "description": "OpenCode plugin for Feature Factory agents - provides sub-agents and skills for validation, review, security, and architecture assessment",
   "license": "MIT",
@@ -15,7 +15,6 @@
     "assets",
     "skills",
     "agents",
-    "command",
     "bin"
   ],
   "keywords": [

package/command/mini-loop/documentation/document.md

@@ -1,15 +0,0 @@
----
-description: Write documentation pass for mini-loop
-subtask: true
-agent: documenting
-model: openai/gpt-5.3-codex
----
-
-Update repository documentation for the approved mini-loop implementation from `$ARGUMENTS`.
-
-Requirements:
-
-1. Reflect shipped behavior and operational steps exactly.
-2. Apply prior documentation rework feedback when present.
-3. Keep updates concise and cross-link impacted docs when needed.
-4. Return a concise documentation update report with changed docs and rationale.

package/command/mini-loop/documentation/gate.md

@@ -1,16 +0,0 @@
----
-description: Apply documentation mini-loop gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest documentation review input from `$ARGUMENTS` and apply this gate exactly:
-
-- APPROVED only when `CONFIDENCE` is strictly `>95`, `CHANGE_REQUESTED=NO`, and `UNRESOLVED_DOCUMENTATION_ISSUES=0`
-- REWORK when not approved and iteration < 5
-- ESCALATE when iteration == 5 and still not approved
-
-Output exactly one line:
-
-`MINI_LOOP_DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/mini-loop/documentation/review.md

@@ -1,17 +0,0 @@
----
-description: Review documentation pass for mini-loop
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Review the latest mini-loop documentation pass from `$ARGUMENTS`.
-
-Required output fields:
-
-1. `CHANGE_REQUESTED=YES|NO`
-2. `UNRESOLVED_DOCUMENTATION_ISSUES=<integer>`
-3. `CONFIDENCE=<0-100>`
-4. concise documentation rework instructions when change is requested
-
-Return a deterministic structured documentation review result with no file persistence.

package/command/mini-loop/documentation/run.md

@@ -1,16 +0,0 @@
----
-description: Run documentation mini-loop until gate passes
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 5
-  until: documentation gate is APPROVED
-return:
-  - /mini-loop/documentation/document {as:mini-doc-pass} $ARGUMENTS
-  - /mini-loop/documentation/review {as:mini-doc-review} $RESULT[mini-doc-pass]
-  - /mini-loop/documentation/gate $RESULT[mini-doc-review]
-  - If `MINI_LOOP_DOCUMENTATION_GATE=REWORK`, continue loop with prior documentation review feedback included in the next documentation pass.
----
-
-Reply with only: "Documentation phase started"

package/command/mini-loop/implementation/build.md

@@ -1,15 +0,0 @@
----
-description: Build implementation pass for mini-loop
-subtask: true
-agent: building
-model: openai/gpt-5.3-codex
----
-
-Implement the current mini-loop requirements from `$ARGUMENTS`.
-
-Requirements:
-
-1. Apply requested code rework when present.
-2. Add or update tests for behavioral changes.
-3. Run lint/typecheck/tests only for impacted scope.
-4. Return a concise implementation report with changed files, tests run, and known open issues.

package/command/mini-loop/implementation/gate.md

@@ -1,16 +0,0 @@
----
-description: Apply implementation mini-loop gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest implementation review input from `$ARGUMENTS` and apply this gate exactly:
-
-- APPROVED only when `CONFIDENCE` is strictly `>95`, `CHANGE_REQUESTED=NO`, and `UNRESOLVED_BLOCKING_ISSUES=0`
-- REWORK when not approved and iteration < 10
-- ESCALATE when iteration == 10 and still not approved
-
-Output exactly one line:
-
-`MINI_LOOP_IMPLEMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/mini-loop/implementation/review.md

@@ -1,17 +0,0 @@
----
-description: Review implementation pass for mini-loop
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Review the latest mini-loop implementation output from `$ARGUMENTS`.
-
-Required output fields:
-
-1. `CHANGE_REQUESTED=YES|NO`
-2. `UNRESOLVED_BLOCKING_ISSUES=<integer>`
-3. `CONFIDENCE=<0-100>`
-4. concise rework instructions when change is requested
-
-Return a deterministic structured review result with no file persistence.

package/command/mini-loop/implementation/run.md

@@ -1,16 +0,0 @@
----
-description: Run implementation mini-loop until gate passes
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 10
-  until: implementation gate is APPROVED
-return:
-  - /mini-loop/implementation/build {as:mini-impl-build} $ARGUMENTS
-  - /mini-loop/implementation/review {as:mini-impl-review} $RESULT[mini-impl-build]
-  - /mini-loop/implementation/gate $RESULT[mini-impl-review]
-  - If `MINI_LOOP_IMPLEMENTATION_GATE=REWORK`, continue loop with prior review feedback included in the next build input.
----
-
-Reply with only: "Implementation phase started"

package/command/mini-loop/start.md

@@ -1,11 +0,0 @@
----
-description: Mini-loop two-stage workflow entrypoint
-subtask: false
-agent: general
-model: openai/gpt-5.4
-return:
-  - /mini-loop/implementation/run {as:implementation-phase} $ARGUMENTS
-  - /mini-loop/documentation/run $RESULT[implementation-phase]
----
-
-Reply with only: "Mini-loop started"

package/command/pipeline/building/breakdown.md

@@ -1,18 +0,0 @@
----
-description: Break final plan into atomic tasks
-subtask: true
-agent: building
-model: anthropic/claude-opus-4-6
----
-
-Read the approved final plan from `$ARGUMENTS` and produce atomic tasks.
-
-Each task must include:
-
-- task id
-- title and description
-- target files
-- dependencies
-- acceptance criteria
-
-Return structured `TASKS` output (no file persistence).

package/command/pipeline/building/implement-batch.md

@@ -1,26 +0,0 @@
----
-description: Implement validated batches with Codex
-subtask: true
-agent: building
-model: openai/gpt-5.3-codex
----
-
-Read `BATCHES` input from `$ARGUMENTS` and implement each batch.
-
-Execution strategy:
-
-1. Process batches in dependency order — a batch may only start after all batches it depends on have completed.
-2. Within each batch, launch **parallel sub-agents** (type: `building`) — one per task — for tasks that have no mutual dependency edges. Use concurrent tool calls to maximize throughput.
-3. Tasks within the same batch that share file targets or have explicit dependency edges must run sequentially.
-4. Wait for all tasks in a batch to complete before starting the next batch.
-
-For each task (inside its sub-agent):
-
-1. implement code changes
-2. add/update tests
-3. run lint/typecheck/tests for impacted scope
-4. return a structured completion report (no file persistence)
-
-After all batches complete, merge the per-task completion reports into a single `IMPLEMENTATION_REPORT` output.
-
-This command performs implementation only; reviewing is triggered by `/pipeline/building/run` and by rework flow.

package/command/pipeline/building/run.md

@@ -1,13 +0,0 @@
----
-description: Run build phase from approved plan
-subtask: false
-agent: general
-model: openai/gpt-5.4
-return:
-  - /pipeline/building/breakdown {as:build-tasks} $ARGUMENTS
-  - /pipeline/building/validate-batch {as:build-batches} $RESULT[build-tasks]
-  - /pipeline/building/implement-batch {as:build-implementation} $RESULT[build-batches]
-  - /pipeline/reviewing/run {as:review-phase} $RESULT[build-implementation]
----
-
-Reply with only: "Building phase started"

package/command/pipeline/building/validate-batch.md

@@ -1,17 +0,0 @@
----
-description: Validate task batches for architecture and dependencies
-subtask: true
-agent: building
-model: opencode/gemini-3.1-pro
----
-
-Read `TASKS` input from `$ARGUMENTS` and create dependency-safe batches.
-
-For each batch:
-
-1. validate architecture and codebase fit
-2. confirm or adjust file targets
-3. flag architectural risks
-4. mark whether tasks can run in parallel
-
-Return structured `BATCHES` output (no file persistence).

package/command/pipeline/complete.md

@@ -1,13 +0,0 @@
----
-description: Finalize pipeline run and summarize outcomes
-subtask: true
-agent: general
-model: openai/gpt-5.4
----
-
-Finalize the pipeline run.
-
-1. Summarize accepted plan, implemented tasks, review outcomes, and assumptions.
-2. Prefer result-based handoff; persist only final user-requested artifacts.
-3. Clear transient pipeline agent context files.
-4. Return concise completion report to user.

package/command/pipeline/documentation/document.md

@@ -1,22 +0,0 @@
----
-description: Documentation write/update pass
-subtask: true
-agent: documenting
-model: openai/gpt-5.3-codex
----
-
-Document the approved code changes and update repository documentation.
-
-Before writing docs, load these skills:
-
-- `ff-todo-management`
-- `ff-mini-plan`
-
-Requirements:
-
-1. Use the latest approved review outputs and implementation artifacts as source of truth.
-2. Update all affected docs so behavior and operational steps match shipped code.
-3. If this is a rework iteration, incorporate documentation reviewer feedback from the previous documentation review.
-4. Summarize what docs were changed and why.
-
-Return a structured documentation update summary (no file persistence).

package/command/pipeline/documentation/gate.md

@@ -1,20 +0,0 @@
----
-description: Apply documentation approval gate
-subtask: true
-agent: reviewing
-model: openai/gpt-5.4
----
-
-Read the latest documentation review input from `$ARGUMENTS` and apply gate exactly:
-
-Skill requirements:
-
-- ChatGPT gate supervisor should keep gate decisions explicit and iteration-aware.
-
-- APPROVED when verdict is `APPROVED` and unresolved documentation issues count is `0`
-- REWORK when verdict is `REWORK_REQUIRED` and iteration < 5
-- ESCALATE when iteration == 5 and still not approved
-
-Output one status line:
-
-`DOCUMENTATION_GATE=APPROVED|REWORK|ESCALATE`

package/command/pipeline/documentation/review.md

@@ -1,22 +0,0 @@
----
-description: Documentation review pass
-subtask: true
-agent: reviewing
-model: opencode/gemini-3.1-pro
----
-
-Review the latest Codex documentation pass for completeness, correctness, and repository doc consistency.
-
-Before reviewing docs, load these skills:
-
-- `ff-report-templates`
-- `ff-severity-classification`
-
-Required output:
-
-1. verdict `APPROVED` or `REWORK_REQUIRED`
-2. unresolved documentation issues (if any)
-3. explicit rework instructions
-4. confidence score (0-100)
-
-Return a structured documentation review result (no file persistence).

package/command/pipeline/documentation/run.md

@@ -1,16 +0,0 @@
----
-description: Run documentation loop after review approval
-subtask: false
-agent: general
-model: openai/gpt-5.4
-loop:
-  max: 5
-  until: documentation updates are approved by documentation reviewer with zero unresolved documentation issues
-return:
-  - /pipeline/documentation/document {as:doc-pass} $ARGUMENTS
-  - /pipeline/documentation/review {as:doc-review} $RESULT[doc-pass]
-  - /pipeline/documentation/gate $RESULT[doc-review]
-  - If `DOCUMENTATION_GATE=REWORK`, continue loop with review feedback for the next document pass.
----
-
-Reply with only: "Documentation phase started"

package/command/pipeline/planning/confirm.md

@@ -1,18 +0,0 @@
----
-description: Confirm whether pipeline can proceed after planning
-subtask: true
-agent: planning
-model: openai/gpt-5.4
----
-
-Read the planning output in `$ARGUMENTS` and decide whether the pipeline may proceed.
-
-Rules:
-
-1. If `PLANNING_GATE=APPROVED`, return:
-   - `PLANNING_PROCEED=YES`
-   - The approved `FINAL_PLAN` content for build input.
-2. If `PLANNING_GATE=REWORK` or `PLANNING_GATE=BLOCKED`, return:
-   - `PLANNING_PROCEED=NO`
-   - A short `USER_CONFIRMATION_REQUIRED` section explaining why continuation needs explicit user confirmation.
-3. Do not invent missing gate values.

package/command/pipeline/planning/gate.md

@@ -1,24 +0,0 @@
----
-description: Apply planning consensus gate
-subtask: true
-agent: planning
-model: openai/gpt-5.4
----
-
-Apply the planning gate to the synthesized consensus input passed in `$ARGUMENTS`:
-
-- `>=75`: APPROVED
-- `50-74`: REWORK
-- `<50`: BLOCKED
-
-Actions:
-
-1. If APPROVED, return the accepted final plan in a `FINAL_PLAN` section.
-2. If REWORK, return explicit divergence feedback so the next planning loop iteration re-plans with clear deltas.
-3. If BLOCKED, return explicit user-decision-needed rationale.
-
-Always include one status line in your final output:
-
-`PLANNING_GATE=APPROVED|REWORK|BLOCKED`
-
-If APPROVED, include a `FINAL_PLAN` section that becomes input to the build phase.