Builder Prototypes

Three small pieces of an early software-builder experiment: write a request, assemble its prompt, run explicitly registered steps. Use them together or independently when you want the handoff between those boundaries to be visible.

The source experiments include June 2025. This is a clean public continuation of their intake/telephone/spine ideas, not the complete historical Builder or a tool that builds software for you. Origin

Trace one request

Python 3.11 or later, from this checkout:

python -m pip install -e .
python -m examples.walkthrough
python -m unittest discover -s tests -v

The walkthrough writes a synthetic request into a temporary queue, reads it back, assembles an ordered prompt, measures it, and passes that result into a second registered step. The actual captured output includes the queue record, complete prompt, final payload and per-step evidence. A separate run tries an unknown step and proves the following step never ran.

Compose your own steps

from builder_prototypes import StepRegistry, run_task

registry = StepRegistry()
registry.register("join", lambda args, payload, context: args["left"] + ":" + args["right"])
result = run_task({
    "payload": {"first": "alpha"},
    "steps": [
        {"step": "join", "left": "{first}", "right": "beta", "save_as": "joined"},
        {"step": "join", "left": "{joined}", "right": "gamma", "save_as": "final"}
    ]
}, registry)
assert result.status == "complete"
assert result.payload["final"] == "alpha:beta:gamma"

There is no dynamic import from task text. A registered callable is trusted Python code; the registry is an explicit dispatch boundary, not a sandbox.

Mechanism	Input → output	Where to follow it
Intake	IntakeRequest → identifier-named JSON file	intake.py
Prompt	payload + ordered PromptPart list → text	prompting.py
Steps	task + StepRegistry → payload and StepEvidence	runner.py

Intake fields must serialize as finite JSON; user/project/task identifiers cannot be paths. Prompt fields must be text, required parts must exist, and the assembled prompt has a character bound. Step arguments substitute {name} in top-level string values; nested objects are not recursively templated. Context wins when it and payload share a key. save_as stores an output for later steps.

Failure and trust boundaries

A callable error, unknown step or unresolved substitution produces a failed result and stops subsequent steps. Invalid task structure can raise before or outside that result path. The evidence records output type/size and bounded error text; payload still holds actual outputs.

Mappings passed to steps are shallow read-only views. Nested objects can still be mutated, and a callback can perform arbitrary process-level effects. The queue's same-directory replacement protects against partial file reads; the pre-existing-name check is not a concurrent-producer lock. Use a unique nonce and one coordinated writer.

No model is called, no queue worker runs forever, and no generated code is installed or executed. A useful next experiment is an explicit durable queue consumer with claim/retry semantics; that is a separate boundary from these helpers.

Detailed reference and lineage · Tests · Security · License