Xal

Introducing the Xal Software Factory

The Xal Software Factory is a process, a scaffold and a Claude Code plugin for building services with agents. It is gated so that every claim is checked by an artifact rather than by an agent’s report of its own work. You can clone it and run it.

It is MIT-licensed. The source is at github.com/xodeeq/xal-factory, the documentation is at factory.getxal.com, and the current release is v0.2.2.

From an idea to a monitored service

The factory covers the whole path, and every stage has an artifact, a gate and a decider:

  1. Idea. One line, into the ops repo’s inbox.
  2. Research and spec. A brief with sources, then a spec in which every flag has a default.
  3. Intake. The spec is admitted verbatim, with its digest recorded in a ledger.
  4. Seed. The service repo arrives with its gate and its pipeline. Its stack is its first decision record.
  5. Plan and critic. The work is split into sessions, each with a risk class, a gate and a retry cap. A script and an agent both check the plan.
  6. Driver. One session runs headless. The gate the workflow runs decides whether it passed, never the agent.
  7. Reader and merge. The result is read against the spec and against the standards, and it merges only inside the autonomy level you set.
  8. Deploy and smoke. A configured adapter deploys, then a smoke gate runs against the live URL.
  9. Monitor and learn. Alert runbooks, a weekday nudge, a cost ledger, and lessons promoted into gates.

Autonomy is configured, never assumed. A plan says which risk classes may merge with no person present. Infrastructure, billing, public surfaces and deletions never do. Every pipeline workflow can be switched off with one command and on again with another, and every one of the factory’s 24 options ships with a default.

What is in the release

v0.2.0, the first public release, brought:

  • The spec, covering the lifecycle from idea to deployment and monitoring, the session types, and the rules for flag defaults and error documents.
  • The pipeline in every seeded service. Driver, chain, merge and reader workflows, configured from one file. The plugin ships the reader agent, /run-session, /idea and /explain.
  • An ops repo scaffold with spec intake, the plan critic, status and the nudge, the cost ledger, and the agents.
  • Deploy and monitoring: a deploy adapter (none or fly), a smoke gate and an alert runbook.
  • An installer and a command line, xal-factory, with init, seed, config, enable, disable, apply and doctor. It runs on the bash 3.2 that ships with macOS.
  • The factory’s own gate: 15 gates, each proven able to fail by a committed fixture.

v0.2.1 fixes three things the first live run found:

  • Any adopter’s driver can now fetch its spec. It used to address the read to a fixed account.
  • Merge and chain now read CI through the Actions API. If they cannot, the run stops at once and names the missing permission rather than failing on a raw 403.
  • A new Credentials page lists each secret’s kind of token, its permissions and its expiry.

v0.2.2 finishes that work:

  • The write token is now a fine-grained token, proven live: a session was driven, read and merged with no person present under one.
  • Seeded services move to Go 1.26.9, which fixes two net/http vulnerabilities. Go 1.25 is out of support.

The proof

The first release was proven end to end before it went out. A service and an ops repo were seeded by the installer into throwaway private repositories, and one small session ran through the whole pipeline:

  • The driver fetched the admitted spec and verified its digest, checked both spend ceilings, ran the session, passed its own gate and opened the pull request.
  • CI was green, and the reader passed on both axes with no findings.
  • With auto-merge off, nothing merged. With it set to allow code-only sessions, the merge workflow merged the pull request.

The session was built, read and merged by the pipeline for $0.32, and that cost is recorded in the ops repo’s ledger.

Install

curl -fsSL https://factory.getxal.com/install.sh | bash

The installer checks your tools, links the xal-factory command and offers the Claude Code plugin. xal-factory init then asks each question with its default showing, and xal-factory doctor checks your tools, credentials and configuration.

The pipeline runs on GitHub Actions and needs a few tokens as repository secrets. The Credentials page says which kind each one is, which permissions it needs, and when it expires. Both GitHub tokens are fine-grained, scoped to the permissions listed there.

Where it comes from

The factory comes from Xal. Every rule in it was earned by a specific failure: a gate that passed because it matched nothing, a deploy blocked for hours by an input one workflow forgot, an agent that reported success after being refused 26 times, a session that cost $20 and recorded nothing. The rules sit next to the failures, so they read as decisions rather than preferences.

Questions and problems go to the repository’s issues.