td-feature-build

td-feature-build — implement one tool, new files only

Implement exactly what the spec says, in your own files, green in isolation. The parallel-build contract is simple: new files only; never edit anything shared (layer*/index.ts, tools/index.ts, cli/agent.ts, docs). That isolation is what lets builders run concurrently.

The canonical tool-file pattern

Every tool file exports a pure …Impl and a register…. Mirror a neighbour in the same layer, but the shape is:

import { z } from "zod";
import type { ToolRegistrar } from "../types.js";          // note the .js extension
import { runBuild, errorResult } from "../result.js";

export const fooSchema = z.object({
  name: z.string().default("foo"),
  intensity: z.number().min(0).max(1).default(0.5),
});

export async function fooImpl(ctx: ToolContext, args: z.infer<typeof fooSchema>) {
  // build via the client; never throw — return errorResult / runBuild on failure
}

export const registerFoo: ToolRegistrar = (server, ctx) =>
  server.registerTool(
    "create_foo",
    { title: "…", description: "…", inputSchema: fooSchema.shape },
    (args) => fooImpl(ctx, args),
  );

ctx is the ToolContext ({ client, knowledge, recipes, logger, vault?, allowRawPython }). …Impl is pure and unit-testable with a mocked client.

Hard rules

• Never throw out of a handler. Validate via the Zod schema; turn TD failures into friendly isError results with errorResult / runBuild / friendlyTdError. Return, don't throw.
• .js import extensions on every relative import (ESM/NodeNext). noUncheckedIndexedAccess is on — guard indexed access.
• Biome: 2-space, double quotes, semicolons, trailing commas, 100-col. Check with ./node_modules/.bin/biome check <yourfiles> directly — npm run lint fails with a false ESLint parse error under the RTK proxy.
• New files only. Your tool file + tests/unit/<feature>.test.ts. Do not touch shared files; report your export names to the integrator instead.