A software factory for AI-assisted development:

• each role — committer, documentalist… — does one job, with only the context it needs;
• tools do the mechanical work; an AI is called only when a decision needs judgement;
• everything keeps working without AI;
• people state the need and accept the result; the line does the work in between (principles).

Status (2026-10-06): runs on every commit of its author, and in CI on the pull requests and nightly gardening of workline and DomoticsCore;

The roles

What each role does and does not, its settings and costs: its page, or all the roles. Checking that a commit holds one change is planned (#192). Why these roles, in this order: the roles panorama.

Documentation

Get started

• Install the binary, then workline setup: the global hooks, your agent, the tools the roles use (install).
• Choose your agent: none, Claude Code, or any command as cmd: (the choice).
• Adopt a repository: workline init (install).
• Add CI: the GitHub or GitLab templates (install).
• Step by step, in ten minutes: the quickstart.

Where it runs

• One routing says which roles each event runs: routing.default.yaml as shipped, changed in .workline/config.yaml.
• A role behaves the same wherever it runs; only the trigger, the agent at hand and how its proposals are applied differ.
• On a forge, one job judges, with the agent and no write token; another applies, with the write token and no AI key.
• Forges: GitHub and GitLab built in; none (forge: local, kept in the clone); any other through a command (cmd:, a Forgejo and Gitea sample, untried on a live instance) — ADR-0016.

flowchart LR
  machine["Your machine<br/>git hooks, workline review"]
  mr["The merge request<br/>judged in CI"]
  main["main<br/>schedules, releases"]
  issues["The issues<br/>the backlog"]
  machine -- git push --> mr
  mr -- a person merges --> main
  main -- gardening opens, follow rebuilds --> mr
  main -- the product owner keeps --> issues
  mr -- a finding outside the change --> issues

Your machine

The merge request

Templates: GitHub Actions, GitLab CI. The review is on the merge request, a person merges (ADR-0011).

main: schedules and releases

Templates: GitHub's gardening and sample, follow in workline.yml; on GitLab, two pipeline schedules and a push to the default branch, all in the same template. workline cuts no releases: it runs before your release tool.

The issues

Each role, from a hook, a script or a CI job: triggers.md.

Gates

• A gate is a checkpoint before merging or releasing: it runs your tools and gives a verdict by rules, never by asking a model.
• Your tools, your thresholds: any command; its exit code, or its SARIF results counted against a max set before it runs.
• Three outcomes for each check: pass, finding, or error — a tool missing, crashed or unreadable fails the gate, never passes it (an optional check is still reported).
• Run with workline gate <name>, or as gate:<name> in a routing sequence.

gates:
  release:
    checks:
      - {id: load, run: k6 run load/checkout.js, output: exit}
      - {id: deps, run: "osv-scanner scan --format sarif --output {out}/deps.sarif .", output: sarif, max: {error: 0}}

• SonarQube, where a team runs it: its quality gate will be read, never rerun (#203).
• Everything else: the gates spec.
• Not built yet: only a merge request's new findings, posted on it (#202); other outputs (k6 or benchmark JSON); baselines with an expiry date.