Skip to content
DarkPrint
Aautogenstarter-software-factoryPublic

Starter Software Factory

Get blueprint

Download

starter-software-factory-1.1.0.tgz

Every file of this release in one archive, ready to unpack into a folder.

Clone

npx -y darkprint clone autogen/starter-software-factory

There is no repository and no history behind a release. Download hands you its files as they stand, and Clone fetches the same files by name.

release 1.1.0 · digest sha256:121612ae · 2 releases · published Sep 11, 2026

The canonical five-node factory, plan, build, test, debug, release, and the one edge it deliberately does not have: nothing carries the acceptance criteria to the builder.

Tool capabilities0

No tool capability is declared on any card: every node works from its inputs alone.

Node planner, Spec Planner. DOT line 6, card spec-planner@1.0.0. 5 nodes in the graph.

Selectedplannertopology.dot:6spec-planner@1.0.0

1 The graph

5 nodes · 5 edges · 2 absent
Hears from
nothing in this graph
Sends to
tester

2 The card skeleton

spec-planner@1.0.0Open card →
idspec-plannerline 1Filled.

The key a blueprint pins. A DOT node carries card="id@version", and this string is the only way a graph and a card find each other. It may be namespaced, berti/solver-a, so two authors can publish a card under the same short name.

nameSpec Plannerline 2Filled.

What a person calls the node. The drawing prints it and every listing leads with it. Nothing matches on it: that is the id's job, and the two are free to disagree.

typeagentline 3Filled.

Exactly one node-type term from the vocabulary. It says what kind of work the node does and whether a person acts at it: a type under human-in-the-loop, such as human-gate, holds the run until somebody acts; every other type lets it pass. The static analysis groups nodes by this term. Either way it is the author's design choice; nothing here is measured.

phaseplanningline 4Filled.

Which of the five phases the node stands in, any number of them. The phases describe a blueprint's shape rather than placing every node in one. Intake, retrieval and routing are real work that none of the five names, so declaring none is a valid answer.

actionTurn the incoming request into two separate artefacts, an ordered build brief, and the acceptance criteria the finished work will be judged against.lines 6–8Filled.

The operation, in one line, short enough to read off a drawing. It is prose for whoever opens the card. The agent is instructed by spec, and nothing parses this line.

specRead the feature request you are handed and turn it into two separate artefacts, written independently of one another. On plan, set out the ordered steps someone would follow to build the thing, naming for each step the file or module it touches and what exists once it is done. On criteria, set out the conditions the finished work must satisfy, one per line, each phrased so a machine can decide it: an observable behaviour, an input paired with the output it must produce, or a measurable limit. Keep the two apart, a step is not a criterion, and a criterion that merely restates a step tests nothing. Write no code yourself, and never weaken a criterion to make it easier to meet.123 wordslines 9–17Filled.

The instructions handed to the agent when someone runs the graph on their own machine. They must stand on their own, because the agent never sees the rest of the graph. They must not carry what the graph withholds: if the text supplies information no edge brings to this node, the isolation the graph draws exists only on paper. One check reads this field, card/spec-too-thin, and it only measures length.

modelclaude-opus-5line 18Filled.

Which model the agent is instantiated with, written the way the provider writes the identifier. A default rather than a binding: a graph's model_stylesheet sets the model for every node matching a shape, an explicit field here outranks the sheet, and whoever runs the blueprint outranks both. Absent on most cards, which means the node takes whatever the graph or the runner supplies.

agentPlannerline 19Filled.

A label the card's author chose for the agent behind the node. Nothing checks it.

skillskills/spec-planner.mdline 22Filled.

Where the written procedure for this agent lives, as a path inside the repository you run from. It is only a pointer: no skill document travels in a DarkPrint bundle, and you write the file it names. A node whose spec field holds the whole instruction declares none.

toolsnone requiredline 20Left empty by this card.

tool capability terms from the vocabulary: what the node is permitted to do. This does not say which server supplies the capability; the mcp field answers that. A node can carry either field without the other.

mcpno server is namedline 21Left empty by this card.

The MCP servers the node reaches, under the names they are registered with on the machine that runs the graph. Free text by design: an MCP server is a process somebody installed, and the vocabulary has no term for one.

paramsnone setnot writtenLeft empty by this card.

Nested configuration for the node, free-form but JSON-serializable. It travels with the card to whoever runs the graph; nothing on this site interprets a key of it.

inputsrequest: textlines 24–27Filled.

The ports data arrives on, each with a name and a data-type term from the vocabulary. Every incoming edge is checked against them: an edge whose source produces nothing this node accepts is reported as bundle/type-mismatch.

request: text. The feature request the run was started with, in the requester's own words.

outputsplan: plan, criteria: acceptance-criterialines 28–34Filled.

The ports data leaves on. An output type makes an edge into the next node meaningful. The next node's declared inputs and prohibitions are checked against it.

plan: plan. The ordered build steps, each naming what it touches and what exists when it is done. criteria: acceptance-criteria. The conditions the finished work must satisfy, one per line, each machine-decidable.

dependenciesno upstream node is namedline 35Left empty by this card.

Cards this one expects to hear from, by id. This is the one card field that names topology, so it can point back at a line in the DOT on its own. The DOT still decides what is wired; this field says what the author expected to be wired.

cannotno type is refusedline 36Left empty by this card.

Data types that must never arrive, written as vocabulary term ids. Every incoming edge is checked against every entry, and an edge that can carry that type, or a narrower one, is refused as bundle/prohibition-violated. This is the half of the node's refusals that the checker enforces; will_not is the other half, which nothing checks automatically.

will_notwrite any of the code it plans, weaken a criterion to make it easier to meetlines 37–39Filled.

What the node promises never to do, in the author's own sentences. Nothing checks an entry here, and nothing can: a promise like "never opens a shell" cannot be read off a graph. It is addressed to whoever reads the card and to the agent instantiated from it, which is why it is a field of its own rather than a second kind of entry inside cannot.

risk_markersnone declaredline 41Left empty by this card.

risk-marker terms the author declares for the node. The static analysis subtracts each distinct marker's weight from the blueprint's static risk-exposure reading, once per blueprint however many nodes carry it. An empty list is a valid answer. Three markers are also read off the graph whether or not a card declares them: unbounded loops, unvalidated external access and criteria leaks.

notesThe plan port is deliberately not wired to builder in this blueprint, and the gap is the lesson rather than an oversight. Doc 3 §4.1 defines criteria-leak over a *path* from the criteria producer to the node whose artefact they judge, and the analyzer reads that path at node level, so any edge at all from this node into an implementation node establishes the marker, whichever port it carries. The builder is therefore handed its brief when the graph is instantiated, and nothing leaves this node except the criteria, which go to the tester. The other end of that gap is written down too: code-builder@1.0.0 lists acceptance-criteria under cannot, so an edge from here into the builder is refused by the resolver as well as charged by the analyzer.129 wordslines 42–51Filled.

The author's commentary on the card, addressed to whoever reads it. Nothing checks it.

version1.0.0line 53Filled.

Semver of the card itself. A published version is never edited in place, so a pinned id@version means the same content forever and a change ships as a new version beside it.

authorautogenline 54Filled.

Who wrote the card. It is excluded from the card's digest, along with provenance. Two cards describing the same node are the same card, whoever typed them.

provenancenot statednot writtenLeft empty by this card.

Where the card came from when it did not start here, such as the blueprint it was forked from or the document behind it. Free text, and excluded from the card's digest.

filled, left empty; both are valid. The skeleton is the card’s fields with what each one is for: open a row to read it. Long values are cut at two lines until the row is opened. This card is pinned by planner at topology.dot line 6.

Files

AautogenThe canonical five-node factory, plan, build, test, debug, release, and the one edge it deliberately does not have: nothing carries the acceptance criteria to the builder.sha256:121612…Sep 11, 2026
  • README.mdwhat this blueprint is, its digest, and how to run it
  • cards/5 pinned cards, one document each
  • topology.dotthe topology, as the author wrote it
7 entries · 5 pinned cards inside cards/Open README

README.md

Starter Software Factory

The canonical five-node factory, plan, build, test, debug, release, and the one edge it deliberately does not have: nothing carries the acceptance criteria to the builder.

blueprint      starter-software-factory
bundle digest  sha256:121612ae5535c9502ce87f7f9e008a071c8b407b5fecb8c68b9b98765d92f9a1
nodes          5
cards pinned   5

The digest is taken over topology.dot and the digest of every card version pinned in it. Recompute it to confirm these files are the ones DarkPrint read. One changed byte gives a different digest.

Run it

This runs on your machine. DarkPrint hands out the files and analyses them statically. It executes nothing and holds none of your provider keys.

This folder carries the topology and its pinned cards, nothing compiled. To compile them into a pipeline a graph runner takes, run darkprint export <dir> --attractor. It writes Attractor DOT to stdout, and that file opens with the same two lists this README carries under What these files leave to the runner. Adapting the result, or building the run yourself from these files instead, is your own harness's job.

4 of the 5 nodes name the model they run on, in their card's own model field. Read it off cards/<ref>.yaml; whether your harness honours it is yours to decide.

What is in the folder

topology.dot   node ids, edges, and the card version pinned on each node
cards/         the pinned cards, as the registry stores them; each carries the `spec` that becomes its node's prompt
README.md      this file

5 of the nodes in this bundle name a skill document. There is no skills/ directory above and there is not meant to be: DarkPrint stores the pointer and reads nothing at the other end of it. The paths are relative to the repository you run this blueprint from, and writing the documents is yours to do. Nothing here needs them to run, because every card carries its own spec inline.

planner    skills/spec-planner.md
builder    skills/code-builder.md
tester     skills/acceptance-tester.md
debugger   skills/targeted-debugger.md
deployer   skills/release-gate.md

What these files leave to the runner

Attractor reads more attributes than a DarkPrint blueprint has fields to set. Compile these files into a pipeline, by the command above or by hand, and the names below are the ones nothing in this folder sets. Write them in where your run needs them, and expect a later export of this blueprint to overwrite the whole compiled file. Appendix A of the Attractor spec tabulates most of them; the rest are named by the retry rules in §3.5, by the handler pseudocode in §4, and by §9.7's tool call hooks.

Left out, these fall to the runner and the pipeline still runs. The Attractor spec states a value or a behaviour for each one's absence, in Appendix A or in the handler pseudocode that reads it, so what you get is a choice nobody in this folder made:

  • graph: model_stylesheet, default_max_retries, default_max_retry, default_fidelity, retry_target, fallback_retry_target, stack.child_workdir, tool_hooks.pre, tool_hooks.post
  • node: goal_gate, retry_target, fallback_retry_target, fidelity, thread_id, timeout, llm_provider, reasoning_effort, auto_status, allow_partial, join_policy, max_parallel, manager.poll_interval, manager.max_cycles, manager.stop_condition, manager.actions, stack.child_autostart, tool_hooks.pre, tool_hooks.post
  • edge: fidelity, thread_id, loop_restart

Left out, these have nothing to fall to. The handler a node's shape selects reads each one directly, and with no value it refuses or goes round again while the rest of the compiled file reads as though the node would run. Read §4's handler section for the shape you are compiling before you leave one of these unset:

  • graph: stack.child_dotfile
  • node: human.default_choice

The nodes

nodecard
plannerspec-planner@1.0.0
buildercode-builder@1.0.0
testeracceptance-tester@1.0.0
debuggertargeted-debugger@1.1.0
deployerrelease-gate@1.0.0

Exported from https://www.darkprint.io/blueprints/starter-software-factory

History

each release is a frozen snapshot, addressed by its digest
  • 1.1.0sha256:121612…latest

    The canonical five-node factory, plan, build, test, debug, release, and the one edge it deliberately does not have: nothing carries the acceptance criteria to the builder.

    autogen · Sep 11, 2026

  • 1.0.0sha256:a11411…

    The canonical five-node factory, plan, build, test, debug, release, and the one edge it deliberately does not have: nothing carries the acceptance criteria to the builder.

    orin · Aug 30, 2026

There is no repository behind a release, so there is nothing to pull.

Community notes (0)

No notes yet.

Nobody has posted about this blueprint yet.

Sign in to post a note.