[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-95857":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":16,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":17,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":18,"hasPages":18,"topics":20,"createdAt":9,"pushedAt":9,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":15,"starSnapshotCount":15,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},95857,"ai-software-factory","coleam00\u002Fai-software-factory","coleam00","A repository that ships without anyone reading the diff: GitHub issues in, merged pull requests out, with the gates that make that defensible.",null,"Python",181,29,4,1,0,37,4.43,false,"main",[],"2026-09-21 02:04:28","# AI Software Factory\n\nA repo that takes work in as an issue and ships validated code out, with nobody at\nthe keyboard.\n\nYou file an issue. It gets checked against your mission, planned, built, judged by\nsomething that did not write it, and merged. A scheduled run re-tests what already\nmerged and files its own bugs. Nobody reads the diff.\n\nSome people call this a dark factory, after lights-out manufacturing. Same idea.\nIt builds software from a PRD, so I call it a software factory.\n\nThe automation is the easy half. Being able to trust a merge nobody read is the\nhard half, and most of what is in here exists for that.\n\n---\n\n## Set it up\n\nPaste this to your coding agent, in the repo you want the factory in:\n\n```\nHelp me set up my own AI software factory in this repo using this GitHub repo:\nhttps:\u002F\u002Fgithub.com\u002Fcoleam00\u002Fai-software-factory\n\nRead its README and follow the \"Instructions for the agent\" section.\n```\n\nThat is the install. It clones this, runs the installer, then walks you through\nthe three files nobody can write for you.\n\n**You need:** git, Python 3.10+, [`gh`](https:\u002F\u002Fcli.github.com) authenticated, a\nGitHub remote, and a coding agent CLI. Everything else it installs, including the\nworkflow engine.\n\nIf you would rather do it by hand:\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fcoleam00\u002Fai-software-factory ~\u002Fai-software-factory\ncd \u002Fpath\u002Fto\u002Fyour-repo\npython ~\u002Fai-software-factory\u002Fbin\u002Ffactory.py init\npython factory\u002Fdoctor.py\n```\n\n---\n\n## Instructions for the agent\n\n> [!IMPORTANT]\n> This section is addressed to the coding agent, not to you. If you are reading it\n> yourself, the manual commands above do the same thing.\n\n**1. Install it.**\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fcoleam00\u002Fai-software-factory ~\u002Fai-software-factory\npython ~\u002Fai-software-factory\u002Fbin\u002Ffactory.py init\n```\n\nRun `init` from the root of the user's repo. It writes the runtime, the workflow\npack, the skills and the governance templates, creates the GitHub labels that are\nthe state machine, and installs [Archon](https:\u002F\u002Fgithub.com\u002Fcoleam00\u002Farchon) if it\nis not already there. It changes no application code.\n\n**2. Write the three files with them.** This is the actual work, and `init`\ninstalls a skill for it: read `.claude\u002Fskills\u002Ffactory-setup\u002FSKILL.md` and follow it.\n\nRead the repo FIRST. The language, the test command, the start command, the entry\npoint and the routes are all in there. Then ask at most four questions, each with\nyour proposed answer already filled in so the cheapest reply is \"yes\". Every\nquestion the repo already answered is a reason to regret starting.\n\nWhat comes out of it:\n\n| file | what you are writing |\n|---|---|\n| `MISSION.md` | what this product is, and the list of things it must **never** become |\n| `harness\u002FEND-TO-END.md` | two to five journeys, in plain English, that a real user takes |\n| `.factory\u002Fholdout\u002FHOLDOUT.md` | the same product composed, where the builder cannot read it |\n\n**The out-of-scope list in `MISSION.md` is the one that decides whether any of this\nworks.** It is how the factory recognises that a plausible, well-argued, easy\nrequest is drift rather than a good idea. Do not ask the user to produce it from\nnothing. Propose seven entries yourself from what you read, make them things a\nreasonable person would actually ask for, and have them strike the wrong ones.\n\nWrite the holdout yourself and do not ask at all. Then tell them it exists and that\nthey should read it, because it is the file the whole auto-merge rests on.\n\nJourneys describe what the product **does today**, never what it should do. A\njourney for behaviour that does not exist yet leaves the gate red before the first\nlap, and nothing can merge, including the change that would make it pass.\n\n**3. Run `python factory\u002Fdoctor.py` and show what failed.** It will fail. That is\nit working: the doctor is a checklist and its failures are the remaining todo\nlist, each naming the autonomy level it blocks. Do not try to make it green in one\nsitting.\n\n**4. Stop there.** Do not raise the autonomy dial, do not run `factory arm`, and do\nnot start the loop. Those come after a lap has run and the user has watched it.\n\n---\n\n## The three files that are yours\n\nEverything else ships done. These three are the build.\n\n**`MISSION.md`** is what the product is, and what it must never become. The\nout-of-scope list is the part that does work: it is how an agent recognises that a\nplausible, well-argued, easy request is drift. Without it every request is arguably\nin scope, because almost every feature is defensible on its own. Aim for at least\nfive, and make them things a reasonable person would actually ask for.\n\n**`harness\u002FEND-TO-END.md`** is two to five journeys in plain English. An agent\nreads them every validation run, drives your app, and reports what it saw. Name\nthe value you expect. \"The page loads\" passes against an app that returns an empty\nbody forever.\n\n**`.factory\u002Fholdout\u002FHOLDOUT.md`** is the same product, composed, in a directory the\nbuilder is blocked from reading. Everything in `harness\u002F` sits inside the builder's\noptimisation loop: it can read those checks and iterate until they are green, and\ngiven enough attempts it will. The holdout is different only because the builder\nnever sees it, and that is the only honest reason to merge code nobody reviewed.\n\nThe journeys and the scenarios are markdown, not scripts, on purpose. A scripted\nend-to-end runs the same two requests forever and goes stale the week after it is\nwritten, and the staleness is invisible because it still passes.\n\n---\n\n## The autonomy dial\n\n```\n0  workflows exist, you run them by hand           \u003C- every install starts here\n1  an accepted issue becomes a branch and a PR\n2  + the validator runs and writes a verdict\n3  + it MERGES when every structural gate is green \u003C- the target\n4  + it triages its own issues, and the scheduled regression files its own bugs\n5  + it writes its own issues from the mission\n```\n\n**Level 3 is the destination.** It is the first level where code merges without a\nhuman reading it. A factory that stops at 2 is a code generator with a queue, and\nyou are still the bottleneck you were trying to remove.\n\n`factory level 3` refuses until the doctor says the evidence supports it: real\njourneys, a holdout, a mutation set shown to catch things, a ratchet with numbers\nin it, and a channel that can reach you.\n\n---\n\n## What is enforced in code, not in a prompt\n\nA gate written as an instruction in a prompt is a suggestion with good manners.\nThese are not.\n\n- **The merge.** A script reads a verdict file and branches on it. Never a model\n  deciding to merge.\n- **Proof it ran.** `APP_STARTED` and `E2E_PASSED` must appear in the output. A\n  check that never ran produces no failures, and \"did anything fail?\" reads that as\n  success.\n- **Evidence, not a claim.** Every assertion the journey agent reports carries the\n  value it actually observed. A report that restates the expectation instead of\n  what happened is rejected before anything is counted.\n- **The protected list.** A PR touching governance, the harness, the locks or the\n  holdout is auto-rejected first, and the validator reads the rulebook from the\n  **base branch**, so a PR cannot weaken the rules it is about to be judged by.\n- **The ratchet.** Assertion counts have a floor in a protected file, so \"delete\n  the check and lower the number\" is not available to the factory.\n- **The stop button.** A local file and a remote label, because they fail in\n  different places. The remote half fails closed: any error reading it counts as\n  stopped.\n- **The watchdog.** A tick has no memory, so it cannot notice it is repeating\n  itself. A ledger records every dispatch and seven detectors halt the factory on\n  the shapes of stuck. One rejected PR re-validated 68 times in three and a half\n  hours before this existed.\n\n---\n\n## Commands\n\n```bash\nfactory init          # install into this repo\nfactory doctor        # the checklist. It will fail. That is it working.\nfactory status        # what is in flight, what the dial is, what needs you\nfactory run implement gh:issue:4   # one lap, by hand, watching\nfactory level 1       # raise the dial (refused without the evidence)\nfactory arm           # install the schedule (refused below level 1)\nfactory halt          # the stop button\n```\n\nAnd the three things `init` installs that actually run it:\n\n```bash\nbash .factory\u002Floop.sh        # the dispatcher. One tick a minute, forever.\npython .factory\u002Fmonitor.py   # prints only what you would act on\n.factory\u002Fnotify.sh           # where escalations go. Set one of these first:\n                             #   FACTORY_NTFY_TOPIC, FACTORY_WEBHOOK_URL\n```\n\nSet a notification channel before you leave it running. The watchdog can halt the\nfactory on its own. It cannot tell you that it did.\n\n---\n\n## What it does not do\n\n**It does not push.** Filing an issue does not trigger a run. A scheduler wakes on\na timer, reads the state, and dispatches. An issue filed at 09:01 waits for the\nnext tick. A push trigger that breaks fails silently and looks exactly like a\nfactory with nothing to do. A poll that breaks is a poll you can see not running.\n\n**It does not judge taste.** A green gate never means the product is good. It means\nthe layer a machine can check is intact.\n\n**It does not own your process.** The node prompts in `.archon\u002Fworkflows\u002Ffactory\u002F`\nare yours to rewrite. That is where your planning step and your review step go.\n\n---\n\n## Cost\n\nOne published comparison, on one task: a solo agent produced a non-functional\nresult in about twenty minutes for single-digit dollars. A planner, generator and\nevaluator harness where the evaluator drove the live page produced a working result\nin about six hours for roughly twenty times the cost.\n\nTwenty times, for the only version that worked. Instrument your tokens on day one.\nProjections for this are wrong by 10-20x in the same direction every time.\n\n---\n\n## Layout\n\n```\nbin\u002Ffactory.py       the CLI\nbin\u002Fsync-to.py       push template fixes into a repo that already installed\nbin\u002Faudit.py         cross-file invariants no single file can check alone\ntemplate\u002F            what init copies in\n  factory\u002F           the runtime: dispatcher, state machine, guard, gate, merge\n  factory\u002F_selftest.py  the harness for that runtime, run by doctor\n  harness\u002F           the gate ladder, the mutation runner, END-TO-END.md\n  .archon\u002Fworkflows\u002F the five workflows and their prompts\n  .claude\u002Fskills\u002F    the same loop, by hand\ndocs\u002Ffirst-hour.md   what to do after init, in order\ndocs\u002Fincidents.md    every way this has been wrong, and the mechanism each time\n```\n","AI Software Factory 是一个自动化软件交付系统，将 GitHub Issue 转化为经验证的合并代码，全程无需人工审阅 diff。其核心功能包括：基于 MISSION.md 的需求约束驱动开发、自动生成与隔离评审（holdout）的双轨验证机制、内置状态机标签管理、端到端行为测试驱动的回归巡检，以及与编码代理（如 Claude）协同的初始化工作流。技术上依赖 Python 3.10+、GitHub CLI 和轻量工作流引擎 Archon，强调可审计性与信任保障而非单纯自动化。适用于追求高可信度无人值守交付的中小型工程团队、AI 编程实验项目或需要严格变更管控的内部工具链场景。",2,"2026-09-05 02:30:03","CREATED_QUERY"]