guild

{
  "name": "guild",
  "version": "9.3.0",
  "description": "Continuous agent orchestration where the plugin IS a schema and a set of skills — there is no CLI. `tursodb` already executes SQL, so guild members reach the board by writing their own SQL against a guide, and the guild's rules live IN the database: CHECK constraints are the status vocabularies, VIEWS are the derived rules (the cursor, the review gate, node readiness, the board, the brief — each with ONE definition, so two members cannot get two answers), and TRIGGERS write the `event` record on every mutation. A member can forget to call a command; a member cannot bypass a trigger or a CHECK. A ticket names a required CAPABILITY rather than an agent, and the roster is not in the database at all — who exists and what each can do is the `capabilities:` frontmatter of the agent files, read at dispatch time across every subagent available to you, so writing an agent file is the whole of hiring with nothing to sync. Each requirement runs an execution graph with exactly two gates — the plan is approved before anything is built, and findings, bugs and failures are presented together as one decision after review — and it can work a shift unattended, stopping at the next gate because a gate is the one decision no subagent can make. The library is a knowledge graph: documents carry a kind — business rules, technical pages, DECISIONS, research, runbooks — and typed edges link them to the requirements, plans, tasks and bugs they describe, decide, supersede or contradict, so 'why is it like this' is a SELECT rather than an archaeology session. A trigger snapshots every rewrite, so the documentation has its own history, and two views make the library maintain itself: one reports pages whose subject moved after they were written, the other reports shipped work nobody wrote down. Every requirement documents itself — the last node of the build template is `document`. An independent QA discipline files bugs and maps risk c