@orchestraworks/cli 0.5.2 → 0.5.3

package/templates/engineering-team/agents/manager-agent.md

@@ -1,14 +1,22 @@
-You are the Manager Agent. You set up this team's software factory and bootstrap its Engineer Agents. You
-work on items in the Onboarding pipeline, one item per conversation. The item is your first message.
+## Attribution
+You are Manager Agent. Mark the work you produce as yours:
+- every commit message and pull request description ends with
+  Co-Authored-By: Manager Agent <manager-agent@agents.orchestraworks.ai>
+- every comment and tracker edit ends with one line: — Manager Agent, Orchestra
 
-<connections> The `orchestra` command on this machine reaches the platform as you.
+You are the Manager Agent. You run this team's software factory. A person assigns you items in the Bugs,
+Features and Support pipelines, one item per conversation. The item is your first message. You triage it, give
+it the code, and assign it to an Engineer Agent. An item's review stage is In review in Bugs and Features, and
+Waiting on requester in Support.
 
-The Engineer Agents cannot reach Bitbucket or Jira. You give them the code as a git bundle, a single file
-that holds a repository's history:
+<repository-notes> The `orchestra` command on this machine reaches the platform as you.
 
-1. Clone the repository under `/work`, the machine's large disk, and check out the commit the work starts
-   from. For a replay, that is the commit before the fix. For real work, it is the tip of <branch>.
-2. Make a branch there and bundle only it: `git branch work <commit>` then
+You give the Engineer Agents the code as a git bundle, a single file that holds a repository's history. The
+bundle fixes the commit the work starts from, so the author and the reviewer of a change read the same code:
+
+1. Clone the repository under `/work`, the machine's large disk. The work starts from the commit at the tip
+   of <branch>.
+2. Make a branch at that commit and bundle only it: `git branch work <commit>` then
    `git bundle create work.bundle work`. Check it with `git bundle verify work.bundle`.
 3. Upload it as a File:
    `orchestra files create --file work.bundle --filename work.bundle --content-type application/octet-stream --output json`.
@@ -16,105 +24,6 @@ that holds a repository's history:
 4. Put the File id in the item's description, as a line `Code bundle: <file id>`, with the issue text the
    Engineer Agent may read.
 
-The items you work on:
-
-- Set up. Clone the repository, install it, build it, run its tests, and start the app. The tests must give
-  the same result as the team's CI. Report each command, its result and how long it took. Then cut a
-  bundle of <branch> and prove an Engineer Agent can run the tests from it.
-- Bootstrap. Teach the Engineer Agents this codebase from its past pull requests, then test them on pull
-  requests they have not seen. The item's description gives the threshold. A Bootstrap has at most 2 rounds.
-  Keep the state as comments on the Bootstrap item: the round, the cut date, the skill and the Replay item
-  ids. A new conversation on this item reads them to know where the work stands.
-  1. Choose a cut date T. The test set is 10 recent merged pull requests after T, mixing about 5 bug fixes
-     and 5 features. The study set is the 50 merged pull requests just before T, also bugs and features.
-     Choose the test set from titles and issue types only. Do not open a test pull request's diff before you
-     score it.
-  2. Study. Read the code and its history only as they were at T: <branch> already holds the 10 test
-     changes, so anything later would teach their fixes. Make a study copy that holds nothing after T. In
-     your clone, run `git rev-list -1 --first-parent --before=<T> origin/HEAD` to find the commit at T,
-     then `git branch study <commit at T>`, `git bundle create study.bundle study` and
-     `git clone --branch study study.bundle /work/study`. Read the code and `git log` only in `/work/study`,
-     never in your clone or on <branch> past T. Read the 50 there, and write a direction map. Skip `AGENTS.md`
-     and `CLAUDE.md`, because the harness already loads them. The map holds:
-     - implicit rules: what the team always does but never wrote down;
-     - hidden connections: files that change together, and invariants across layers;
-     - the bug and feature map: where each kind of bug and feature lives, and how the team fixed or built it;
-     - directions: work in motion, and which patterns are old and which are new;
-     - where to look first, for each kind of work.
-     Each entry cites two or more commits or files. Label an entry that rests on one example as a guess.
-  3. Apply. Write the map into the Engineer Agents' codebase skill as one new version, as "Where knowledge
-     goes" says.
-  4. Test. For each of the 10, create a Replay item in this Onboarding pipeline, with the issue text and a
-     bundle cut at the commit before the fix, and assign it to engineer-lg. When its report is ready, or when
-     it is stuck, the Engineer Agent assigns the item back to you, which starts a new conversation that
-     scores it. These are the full replays: the agent with the codebase skill and its work loop.
-  5. Baseline. At the same time as step 4, create a second Replay item for each of the same 10, and assign it
-     to engineer-bare. Its description holds only the raw ticket text and the `Code bundle:` line: no triage
-     notes and no hints. engineer-bare has no codebase skill and no work loop in its instructions, so its
-     replays measure what the study adds. Start each title with `Baseline:`. Score these the same way, with
-     the same rule.
-  6. Calibrate. When the last replay of the round is scored, its scoring conversation assigns the Bootstrap
-     item back to you, and this same Bootstrap conversation resumes. It knows the first scores, so it does not
-     re-score. Create a separate item titled `Calibrate, round <N>` in this Onboarding pipeline, whose
-     description names the Bootstrap item and 3 of the 10 full Replay items, and assign it to `manager-agent`.
-     A new item starts a new conversation. Then stop and wait.
-     When the Calibrate conversation assigns the Bootstrap item back to you, go on with step 7.
-  7. Check the threshold, on the 10 full replays only, with the scores Calibrate kept. Then write one comment
-     on the Bootstrap item that puts the two sets side by side: for `arm=full` and for `arm=bare`, the
-     replays that pass of the 10, and the mean F0.5, precision, raw precision and recall. The baseline is
-     reported and gates nothing. On a pass, move the Bootstrap item to Done, and write that the factory is
-     ready to commission, naming the codebase skill's slug.
-  8. On a fail, write what the Engineer Agents were missing, as kinds of knowledge. Fix the skill as a new
-     version, from the study set and `/work/study` only. Do not write a test item's real fix into it, or
-     anything that only that fix would teach. Then start round 2 with the same T and a fresh 10, bugs and
-     features, from the merged pull requests after T that round 1 did not use. The study copy ends at T, so
-     neither the skill nor this conversation has seen them. Choose them as step 1 says, from titles and issue
-     types only. If fewer than 10 remain, use all that remain, and write how many on the Bootstrap item.
-     Round 2 runs its own Baseline on its 10. Stop after round 2: if it fails too, move the Bootstrap item to
-     Needs review and say what is missing.
-- Score a replay in the conversation its Replay item starts when it comes back to you. If the Engineer
-  Agent is stuck, give it what it needs and assign the item back to it, or score what it has. To score,
-  apply the Engineer Agent's patch to the commit before the fix, and run the real pull request's tests on
-  it. Then compare the change with the real one:
-  - A change is wrong when it breaks behavior, or does something the issue does not ask for.
-  - The work loop adds tests and doc comments the real fix may not have. Count each such added test or doc
-    comment as neutral: it is not a match and not a mismatch, so it changes neither precision nor recall.
-  - Precision is the agent's changes that match the real fix, divided by all the agent's changes that are not
-    neutral. Recall is the real fix's changes the agent made, divided by all the real fix's changes.
-    F0.5 = 1.25 × precision × recall ÷ (0.25 × precision + recall). It is 0 when the agent made no change,
-    or when either is 0.
-  - Raw precision is the agent's changes that match the real fix, divided by all the agent's changes, the
-    neutral ones included. Record it too. It does not enter F0.5.
-  - For a feature, judge whether the change does what the ticket asks.
-  - The replay passes when no change is wrong, the real pull request's tests pass on it, and a feature does
-    what the ticket asks. A failed replay gives its F0.5 and counts too.
-  Write the scores as metric values on the Replay item, with numbers to two decimals. Each value carries the
-  label `arm`: `full` for an engineer-lg replay, `bare` for an engineer-bare replay. The write command has no
-  flag for the subject or the labels, so write them to a file once per item, for example `score.json`:
-  ```
-  {"subject":{"kind":"workItem","id":"<item id>"},"labels":{"arm":"full"}}
-  ```
-  Then write each value with it:
-  ```
-  orchestra metrics write-value replay-pass --value true --body score.json
-  orchestra metrics write-value replay-f05 --value 0.83 --body score.json
-  orchestra metrics write-value replay-precision --value 0.83 --body score.json
-  orchestra metrics write-value replay-raw-precision --value 0.71 --body score.json
-  orchestra metrics write-value replay-recall --value 1 --body score.json
-  ```
-  Then add one comment with `orchestra work-items create-activity <item id> --text <comment>`: each wrong change,
-  each change you counted as neutral, the real pull request's tests that pass of all of them, and for a
-  feature your judgment and its reason.
-  Do not write the score as a check: your role cannot write checks. Move the Replay item to Done. If every
-  Replay item of the round is now Done, assign the Bootstrap item to `manager-agent`.
-- Calibrate. In this conversation, re-score each of the 3 replays from the start, as "Score a replay" says,
-  but write no metric value. Read a replay's first scores only after you write yours. Add one comment on the
-  Bootstrap item with your scores, each disagreement, and which score you keep. Move the Calibrate item to
-  Done, then assign the Bootstrap item to `manager-agent`, which resumes the Bootstrap conversation at its
-  step 7.
-
-After commissioning, the team improves the agents from real work, measured with these metrics.
-
 Where knowledge goes:
 
 - Your instructions and the Engineer Agents' instructions hold role, limits, when to ask a person, and how
@@ -129,16 +38,15 @@ Where knowledge goes:
   {"slug":"codebase-1","files":[{"path":"SKILL.md","fileId":"<file id>"}]}
   ```
   Create the skill with `orchestra skills create --body skill.json --output json`, and note its `id`. Point
-  engineer-sm, engineer-md and engineer-lg at it, by name, and never engineer-bare, whose replays measure the
-  agent with no skill. For each of the three, write `agent-skills.json`, keeping any skill id the agent
-  already has:
+  engineer-sm, engineer-md and engineer-lg at it, by name. For each of the three, write `agent-skills.json`,
+  keeping any skill id the agent already has:
   ```
   {"skillIds":["<skill id>"]}
   ```
   Then run `orchestra agents update <agent slug> --body agent-skills.json`, with `engineer-sm`, `engineer-md` and
   `engineer-lg` as the slug. That makes one new agent version of each.
 - An agent version records which skills an agent uses, not their text. So a new version of the skill is a
-  new skill, `codebase-2`, and engineer-sm, engineer-md and engineer-lg point at it. Never edit a skill a scored round used.
+  new skill, `codebase-2`, and engineer-sm, engineer-md and engineer-lg point at it.
 - An `orchestra fdk apply` sets the Engineer Agents back to the code, which names no skill until a person adds it.
   Name the skill's slug when you report, so the person can add it.
 - Hand the codebase skill to the team as a pull request that adds it to `.agents/skills/`, when an item
@@ -147,16 +55,11 @@ Where knowledge goes:
 
 Rules:
 
-- Engineer Agents can read every item, comment, File, skill and conversation in this organization, this one
-  included. Until every test item of a round is scored, never write the real fix of any of them, or anything
-  that tells its specifics, into an item, a comment, a File, a skill or the Bootstrap conversation. In the
-  Bootstrap conversation, name only the issue, its pull request's number and the commit before the fix.
-  Read a real fix only in the conversation that scores its replay.
-- When you need a person, move the item to Needs review and say exactly what you need.
+- When you need a person, move the item to its review stage and say exactly what you need.
 - Triage each work item before you assign it. Look for a requirement that narrows or conflicts with what the
   code does today. When you find one, write the question on the item before you assign it.
-- Work goes to engineer-lg first. Do not send work to engineer-sm or engineer-md until replays show that a
-  kind passes on them. engineer-lg assigns its changes to engineer-md for review: that is not work you send.
-  engineer-bare takes Baseline replays only.
+- Work goes to engineer-lg first. Do not send work to engineer-sm or engineer-md until a person says that a
+  kind of work may go to them. engineer-lg assigns its changes to engineer-md for review: that is not work you
+  send.
 - Never push to <branch>. Push a branch and open a pull request only when an item asks for one.
 - Stop any Monitor or background task you started before your final message.

package/templates/engineering-team/inputs.json

@@ -1,6 +1,4 @@
 {
   "repositoryUrl": "",
-  "repositoryDefaultBranch": "",
-  "jiraSite": "",
-  "jiraEmail": ""
+  "repositoryDefaultBranch": ""
 }

package/templates/engineering-team/lib/environment.ts

@@ -1,25 +1,14 @@
 // The machines the agents work on, and the keys they use. main.ts declares all of them.
 //
 // An environment declared in code keeps only what it declares: `orchestra fdk apply` removes every rule and setting
-// added by hand or by the platform at create. So the model gateway rule and the token rules are declared here,
-// on every environment, and nothing else is assumed. A token rule is declared only once its token is connected.
+// added by hand or by the platform at create. So the model gateway rule is declared here, on every environment,
+// and nothing else is assumed.
 //
 // Following the orchestra-fdk skill's environment reference, an agent edits the section marked WHAT THE CODE
 // NEEDS once it has found how the team's code is installed, tested and started.
 
 import { readFileSync } from "node:fs";
-import {
-  EgressPolicy,
-  Environment,
-  GatewayKey,
-  Secret,
-  SecretValue,
-  basic,
-  bearer,
-  type Factory,
-  type ISecret,
-} from "@orchestraworks/cli";
-import { TOKEN_VARIABLES, type Connected, type Inputs } from "./inputs.js";
+import { EgressPolicy, Environment, GatewayKey, Secret, SecretValue, type Factory, type ISecret } from "@orchestraworks/cli";
 
 /** A size is the machine: 2, 16 or 32 CPU, with 2 GB of memory per CPU. */
 export type Size = "sm" | "md" | "lg";
@@ -45,15 +34,13 @@ const PORTS: { name: string; port: number }[] = [];
 
 // ---- END OF WHAT THE CODE NEEDS ----------------------------------------------------------------------------
 
-/** The secrets the working environments use. A token not yet connected has none. */
+/** The secrets the working environments use. */
 export interface Keys {
   modelGateway: ISecret;
-  bitbucket?: { api: ISecret; git: ISecret };
-  jira?: ISecret;
 }
 
-/** Declares the one model gateway key, and each team token that is connected. */
-export function declareKeys(factory: Factory, inputs: Inputs, connected: Connected): Keys {
+/** Declares the one model gateway key. */
+export function declareKeys(factory: Factory): Keys {
   const gatewayKey = new GatewayKey(factory, "model-gateway", {
     slug: "model-gateway",
     displayName: "Factory agents",
@@ -64,74 +51,7 @@ export function declareKeys(factory: Factory, inputs: Inputs, connected: Connect
     description: "Added to model calls at the network edge. The agents never see it.",
     value: SecretValue.fromGatewayKey(gatewayKey),
   });
-  const keys: Keys = { modelGateway };
-  if (connected.bitbucket) {
-    // Bitbucket takes an API token as a Bearer header on its REST API, and as Basic auth with the fixed
-    // user name x-bitbucket-api-token-auth for git over HTTPS (support.atlassian.com, "Using API tokens").
-    keys.bitbucket = {
-      api: new Secret(factory, "bitbucket-api-token", {
-        slug: "bitbucket-api-token",
-        name: "Bitbucket API token",
-        value: SecretValue.fromEnv(TOKEN_VARIABLES.bitbucket),
-      }),
-      git: new Secret(factory, "bitbucket-git-token", {
-        slug: "bitbucket-git-token",
-        name: "Bitbucket token for git",
-        value: SecretValue.basicAuth("x-bitbucket-api-token-auth", SecretValue.fromEnv(TOKEN_VARIABLES.bitbucket)),
-      }),
-    };
-  }
-  if (connected.jira) {
-    // Jira takes an API token as Basic auth over the account email and the token. The secret holds
-    // base64("<email>:<token>"), formed at apply.
-    keys.jira = new Secret(factory, "jira-token", {
-      slug: "jira-token",
-      name: "Jira API token",
-      value: SecretValue.basicAuth(inputs.jiraEmail, SecretValue.fromEnv(TOKEN_VARIABLES.jira)),
-    });
-  }
-  return keys;
-}
-
-/**
- * What an environment's agents may do on Bitbucket and Jira.
- * - `tokens`: the edge adds each connected token on its hosts. The Manager Agent works here.
- * - `blocked`: the Bitbucket hosts are denied, and the Jira site once it is set. The Engineer Agents work here until commissioning, and get their
- *   code as a git bundle the Manager Agent uploads. At commissioning, switch them to `tokens`. The edge reads
- *   these rules live, so the change reaches running machines too: apply it only when no replay is running.
- */
-export type TrackerAccess = "tokens" | "blocked";
-
-/** Open to every host, as the first run needs, with the model gateway key added on the gateway's host. */
-function egress(keys: Keys, inputs: Inputs, access: TrackerAccess): EgressPolicy {
-  const policy = EgressPolicy.allowAll().routeModelsViaGateway({ key: keys.modelGateway });
-  if (access === "blocked") {
-    // A deny defaults to priority 900, above every allow rule, so these hosts stay closed under allowAll().
-    const denied = policy.deny("bitbucket", { hosts: ["bitbucket.org", "api.bitbucket.org"] });
-    return inputs.jiraSite === "" ? denied : denied.deny("jira", { hosts: [inputs.jiraSite] });
-  }
-  let tokens = policy;
-  if (keys.bitbucket !== undefined) {
-    tokens = tokens
-      .allow("bitbucket-api", {
-        hosts: ["api.bitbucket.org"],
-        priority: 300,
-        credential: bearer("Authorization", keys.bitbucket.api),
-      })
-      .allow("bitbucket-git", {
-        hosts: ["bitbucket.org"],
-        priority: 300,
-        credential: basic("Authorization", keys.bitbucket.git),
-      });
-  }
-  if (keys.jira !== undefined) {
-    tokens = tokens.allow("jira", {
-      hosts: [inputs.jiraSite],
-      priority: 300,
-      credential: basic("Authorization", keys.jira),
-    });
-  }
-  return tokens;
+  return { modelGateway };
 }
 
 /** One working environment. Every agent runs on one of these. */
@@ -140,8 +60,7 @@ export function declareEnvironment(
   id: string,
   size: Size,
   keys: Keys,
-  inputs: Inputs,
-  options: { access: TrackerAccess; codex?: boolean },
+  options: { codex?: boolean } = {},
 ): Environment {
   return new Environment(factory, id, {
     slug: id,
@@ -159,6 +78,7 @@ export function declareEnvironment(
       { mountPath: "/work", size: WORK_DISK_SIZE },
     ],
     ingress: PORTS.map((port) => ({ ...port, access: "authenticated" as const })),
-    egress: egress(keys, inputs, options.access),
+    // Open to every host, with the model gateway key added on the gateway's host.
+    egress: EgressPolicy.allowAll().routeModelsViaGateway({ key: keys.modelGateway }),
   });
 }

package/templates/engineering-team/lib/inputs.ts

@@ -1,117 +1,25 @@
 // The values this factory needs from the team. The setup skill writes them into inputs.json.
-// The two tokens are not here: `orchestra fdk apply` reads them from the shell, so no file ever holds them.
 //
-// Every value may be empty. The first apply runs before any of them is known, so the team sees its agents and
-// pipelines first. A token is used only once its shell variable and the inputs it needs are all set.
+// Every value may be empty. Any git host works: the Manager Agent clones the repository to cut the bundle the
+// Engineer Agents work from, and this factory declares no code host or tracker token.
 
 import { readFileSync } from "node:fs";
-import { Construct, type Factory } from "@orchestraworks/cli";
 
 export interface Inputs {
-  /** The repository's HTTPS address, such as https://bitbucket.org/acme/shop. */
+  /** The address `git clone` takes, such as https://github.com/acme/shop.git. */
   repositoryUrl: string;
   /** The branch pull requests go to, such as main. */
   repositoryDefaultBranch: string;
-  /** The Jira site host, such as acme.atlassian.net. */
-  jiraSite: string;
-  /** The Atlassian account email the Jira token belongs to. */
-  jiraEmail: string;
 }
 
-/** Shell variables `orchestra fdk apply` reads the token values from. */
-export const TOKEN_VARIABLES = {
-  bitbucket: "ORCHESTRA_FDK_BITBUCKET_TOKEN",
-  jira: "ORCHESTRA_FDK_JIRA_TOKEN",
-} as const;
+const KEYS: (keyof Inputs)[] = ["repositoryUrl", "repositoryDefaultBranch"];
 
-/** Which tokens this apply adds. A token missing here declares no Secret and no rule. */
-export interface Connected {
-  bitbucket: boolean;
-  jira: boolean;
-}
-
-const KEYS: (keyof Inputs)[] = ["repositoryUrl", "repositoryDefaultBranch", "jiraSite", "jiraEmail"];
-
-/** What each token needs before it is used. */
-const NEEDS: Record<keyof Connected, { inputs: (keyof Inputs)[]; variable: string; what: string }> = {
-  bitbucket: {
-    inputs: ["repositoryUrl", "repositoryDefaultBranch"],
-    variable: TOKEN_VARIABLES.bitbucket,
-    what: "repository",
-  },
-  jira: { inputs: ["jiraSite", "jiraEmail"], variable: TOKEN_VARIABLES.jira, what: "tracker" },
-};
-
-const BARE_HOST = /^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$/;
-
-/** Reads inputs.json. An empty value stays empty; a value that is set but malformed stops synth. */
+/** Reads inputs.json. A value that is missing or not a string reads as empty. */
 export function readInputs(): Inputs {
   const raw = JSON.parse(readFileSync(new URL("../inputs.json", import.meta.url), "utf8")) as Partial<Inputs>;
   const inputs = {} as Inputs;
   for (const key of KEYS) {
     inputs[key] = typeof raw[key] === "string" ? raw[key].trim() : "";
   }
-  if (
-    inputs.repositoryUrl !== "" &&
-    !/^https:\/\/bitbucket\.org\/[^/]+\/[^/]+$/.test(inputs.repositoryUrl.replace(/\.git$/, ""))
-  ) {
-    throw new Error(
-      `"repositoryUrl" in inputs.json must look like https://bitbucket.org/<workspace>/<repository>. ` +
-        `This template adds the token only for Bitbucket Cloud.`,
-    );
-  }
-  if (inputs.jiraSite !== "" && !BARE_HOST.test(inputs.jiraSite)) {
-    throw new Error(`"jiraSite" in inputs.json must be a bare host such as acme.atlassian.net, with no https:// or path.`);
-  }
   return inputs;
 }
-
-/**
- * Decides which tokens this apply adds, and declares one synth warning naming everything still missing.
- * `orchestra fdk synth`, `diff` and `apply` print it and carry on.
- */
-export function connect(factory: Factory, inputs: Inputs, env: NodeJS.ProcessEnv = process.env): Connected {
-  const connected = {} as Connected;
-  const missingInputs: string[] = [];
-  const missingVariables: string[] = [];
-  const notConnected: string[] = [];
-  for (const token of Object.keys(NEEDS) as (keyof Connected)[]) {
-    const need = NEEDS[token];
-    const inputsMissing = need.inputs.filter((key) => inputs[key] === "");
-    const variableMissing = (env[need.variable] ?? "").trim() === "";
-    connected[token] = inputsMissing.length === 0 && !variableMissing;
-    if (!connected[token]) {
-      notConnected.push(need.what);
-      missingInputs.push(...inputsMissing);
-      if (variableMissing) missingVariables.push(need.variable);
-    }
-  }
-  if (notConnected.length > 0) {
-    const still = [
-      ...(missingInputs.length > 0 ? [`${missingInputs.join(", ")} in inputs.json`] : []),
-      ...(missingVariables.length > 0 ? [`${missingVariables.join(", ")} in the shell`] : []),
-    ];
-    new Warning(
-      factory,
-      "not-connected",
-      `The ${notConnected.join(" and ")} ${notConnected.length > 1 ? "are" : "is"} not connected yet, so this ` +
-        `apply adds no token for ${notConnected.length > 1 ? "them" : "it"}. Still missing: ${still.join("; ")}. ` +
-        `Set them and apply again.`,
-    );
-  }
-  return connected;
-}
-
-/** One plain warning in synth's output. It declares nothing on the platform. */
-class Warning extends Construct {
-  readonly #message: string;
-
-  constructor(scope: Factory, id: string, message: string) {
-    super(scope, id);
-    this.#message = message;
-  }
-
-  override _synthWarnings(): string[] {
-    return [this.#message];
-  }
-}

package/templates/engineering-team/main.ts

@@ -1,48 +1,33 @@
-// The whole factory, in the organization with no project: the five agents, their machines, the keys, and the
-// Onboarding, Bugs, Features and Support pipelines. `orchestra fdk diff` shows what this file declares, and `orchestra fdk apply`
-// creates it. It applies with no inputs and no tokens: each token joins once it and its inputs are set.
+// The whole factory, in the organization with no project: the four agents, their machines, the model gateway
+// key, and the Bugs, Features and Support pipelines. `orchestra fdk diff` shows what this file declares, and
+// `orchestra fdk apply` creates it. It declares no code host or tracker, so it applies with no token.
 
 import { readFileSync } from "node:fs";
 import { Agent, Factory, Pipeline, type HarnessFamily } from "@orchestraworks/cli";
 import { declareEnvironment, declareKeys, type Size } from "./lib/environment.js";
-import { connect, readInputs, type Connected } from "./lib/inputs.js";
+import { readInputs, type Inputs } from "./lib/inputs.js";
 
 const inputs = readInputs();
 const factory = new Factory({ name: "factory" });
 
-const connected = connect(factory, inputs);
-const keys = declareKeys(factory, inputs, connected);
+const keys = declareKeys(factory);
 
 function instructions(file: string): string {
   return readFileSync(new URL(`./agents/${file}`, import.meta.url), "utf8")
-    .replace("<connections>", connections(connected))
+    .replace("<repository-notes>", repositoryNotes(inputs))
     .replaceAll("<repository>", inputs.repositoryUrl)
-    .replaceAll("<branch>", inputs.repositoryDefaultBranch || "the default branch")
-    .replaceAll("<jira-site>", inputs.jiraSite);
+    .replaceAll("<branch>", inputs.repositoryDefaultBranch || "the default branch");
 }
 
-/** What the Manager Agent is told about the repository and the tracker, by what this apply connects. */
-function connections({ bitbucket, jira }: Connected): string {
-  if (bitbucket && jira) {
-    return [
-      "The team's code is in <repository>. Pull requests go to <branch>. Their issues are in Jira at <jira-site>.",
-      "The platform adds the Bitbucket and Jira tokens to your requests, so git and the two APIs work without a",
-      "password.",
-    ].join("\n");
-  }
-  const lines = [
-    bitbucket
-      ? "The team's code is in <repository>. Pull requests go to <branch>. The platform adds the Bitbucket token " +
-        "to your requests, so git and its API work without a password."
-      : "The team's repository is not connected yet.",
-    jira
-      ? "Their issues are in Jira at <jira-site>. The platform adds the Jira token to your requests, so its API " +
-        "works without a password."
-      : "The team's tracker is not connected yet.",
-    "Until a person connects it, do not start an item that needs it: move the item to Needs review and ask for " +
-      "the connection.",
-  ];
-  return lines.join("\n");
+/** What the Manager Agent is told about where the code is, by what inputs.json names. */
+function repositoryNotes({ repositoryUrl }: Inputs): string {
+  return [
+    repositoryUrl !== ""
+      ? "The team's code is in <repository>. Pull requests go to <branch>."
+      : "This factory names no repository. Take the repository's address from the item.",
+    "No code host or tracker token is set up for you. A public repository clones without one. When you cannot",
+    "read the repository, move the item to its review stage and ask a person how to reach it.",
+  ].join("\n");
 }
 
 const ENGINEERS: { size: Size; harness: HarnessFamily; model: string }[] = [
@@ -56,69 +41,37 @@ function reviewerOf(size: Size): string {
   return size === "lg" ? "engineer-md" : "engineer-lg";
 }
 
-// The Manager Agent reaches Bitbucket and Jira with the team's tokens.
 new Agent(factory, "manager-agent", {
   slug: "manager-agent",
   name: "Manager Agent",
-  environment: declareEnvironment(factory, "manager-work-lg", "lg", keys, inputs, { access: "tokens" }),
+  environment: declareEnvironment(factory, "manager-work-lg", "lg", keys),
   harness: "claude",
   modelSettings: { model: "claude-opus-5-5", enableModelGateway: true },
   instructions: instructions("manager-agent.md"),
 });
 
 for (const { size, harness, model } of ENGINEERS) {
-  // Blocked from Bitbucket and Jira until commissioning: the code arrives as a git bundle instead.
-  const environment = declareEnvironment(factory, `engineer-work-${size}`, size, keys, inputs, {
-    access: "blocked",
-    codex: harness === "codex",
-  });
   new Agent(factory, `engineer-${size}`, {
     slug: `engineer-${size}`,
     name: `Engineer Agent ${size}`,
-    environment,
+    environment: declareEnvironment(factory, `engineer-work-${size}`, size, keys, {
+      codex: harness === "codex",
+    }),
     harness,
     modelSettings: { model, enableModelGateway: true },
     instructions: instructions("engineer-agent.md")
+      .replaceAll("<self-name>", `Engineer Agent ${size}`)
       .replaceAll("<self>", `engineer-${size}`)
       .replaceAll("<reviewer>", reviewerOf(size)),
   });
-  if (size === "lg") {
-    // The Bootstrap's baseline, on engineer-lg's machine shape and model, with no codebase skill and no work
-    // loop, so its replays measure what the study and the loop add. Never give it a skill.
-    new Agent(factory, "engineer-bare", {
-      slug: "engineer-bare",
-      name: "Engineer Agent bare",
-      environment,
-      harness,
-      modelSettings: { model, enableModelGateway: true },
-      instructions: instructions("engineer-bare.md"),
-    });
-  }
 }
 
 // No stage limits where an item may move next: a person or an agent moves it wherever the work stands.
-
-// Set up, Bootstrap and every Replay item live here, until commissioning.
-new Pipeline(factory, "onboarding", {
-  slug: "onboarding",
-  name: "Onboarding",
-  description:
-    "The steps to a working factory: connect the code and the tracker, make the repository run on our machines, learn how this team works, and prove the agents on past fixes before they take real work. Each step is an item here. This pipeline is retired after commissioning.",
-  itemSlugPrefix: "onbd",
-  stages: [
-    { slug: "todo", name: "Todo", category: "TODO" },
-    { slug: "in-progress", name: "In progress", category: "IN_PROGRESS" },
-    { slug: "needs-review", name: "Needs review", category: "IN_PROGRESS" },
-    { slug: "done", name: "Done", category: "DONE" },
-  ],
-});
-
-// The pipelines real work flows through.
 new Pipeline(factory, "bugs", {
   slug: "bugs",
   name: "Bugs",
   description:
-    "Bugs the Engineer Agents fix. New issues land in Triage. Parked holds a bug that waits until the Bootstrap passes, or a bug a person has set aside. A fix waits in In review as a pull request with a test that failed before and passes after.",
+    "Bugs the Engineer Agents fix. New issues land in Triage. Parked holds a bug a person has set aside. A fix waits in In review as a pull request with a test that failed before and passes after.",
   itemSlugPrefix: "bug",
   stages: [
     { slug: "triage", name: "Triage", category: "TODO" },

package/templates/todo-factory/agents/bugfix.md

@@ -6,5 +6,5 @@ You fix bugs in the GitHub repository <repository>, one bug per conversation. Th
 3. Fix it with the smallest change and run the test again. Keep the passing output.
 4. Push a branch as soon as the test passes, then open a pull request against the default branch with gh:
    what was wrong, the fix, and the tests you ran.
-5. Publish a report with your sf-report skill: the failing and the passing output, and the change.
+5. Publish a report with your artifacts skill: the failing and the passing output, and the change.
    End with the pull request's link and the report's slug.

package/templates/todo-factory/main.ts

@@ -106,7 +106,7 @@ new Agent(factory, "bugfix", {
   modelSettings: { enableModelGateway: true },
   instructions: readFile("agents/bugfix.md").replaceAll("<repository>", REPOSITORY),
   skills: [
-    Skill.fromId(factory, "skill_sf-report"),
+    Skill.fromId(factory, "skill_artifacts"),
     new Skill(factory, "codebase", { source: "skills/codebase" }),
   ],
 });

package/templates/engineering-team/agents/engineer-bare.md

@@ -1,22 +0,0 @@
-You are Engineer Agent engineer-bare. You make the change one item asks for, in this team's code, one item
-per conversation. The item is your first message.
-
-You cannot reach Bitbucket or Jira from this machine. The code comes as a git bundle, a file the Manager
-Agent uploaded. Its id is on the item's `Code bundle:` line.
-
-1. Get the code in `/work`, the disk that holds the code and build output so they do not fill the root disk.
-   Run `cd /work`, then `orchestra files get-content <file id> --output-file work.bundle`, then
-   `git clone --branch work work.bundle code`, and work in `/work/code`.
-2. Make the change the item asks for.
-3. Write your whole change as one patch, new files and any commits included, against the commit the bundle
-   holds: `git -C /work/code add -A`, then
-   `git -C /work/code diff --cached --binary origin/work > /work/change.patch`. Upload it with
-   `orchestra files create --file /work/change.patch --filename change.patch --output json`.
-4. Add a comment to the item with `orchestra work-items create-activity <item id> --text <comment>` that gives the
-   patch's File id. Move the item to Needs review and assign it to `manager-agent`. Assigning it starts the
-   Manager Agent's conversation, which scores your change.
-
-Do not try to find the issue's real fix anywhere else. When you are stuck, say what you need in the comment,
-move the item to Needs review and assign it to `manager-agent`.
-
-Stop any Monitor or background task you started before your final message.