[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-93426":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":11,"openIssues":12,"contributorsCount":12,"subscribersCount":12,"size":12,"stars1d":12,"stars7d":12,"stars30d":12,"stars90d":12,"forks30d":12,"starsTrendScore":12,"compositeScore":13,"rankGlobal":9,"rankLanguage":9,"license":9,"archived":14,"fork":14,"defaultBranch":15,"hasWiki":16,"hasPages":14,"topics":17,"createdAt":9,"pushedAt":9,"updatedAt":18,"readmeContent":19,"aiSummary":20,"trendingCount":12,"starSnapshotCount":12,"syncStatus":21,"lastSyncTime":22,"discoverSource":23},93426,"pawl","agentic-commerce-lab\u002Fpawl","agentic-commerce-lab","Registry-as-ground-truth verification & autonomous research framework for agent-driven development.",null,"Python",122,0,37,false,"main",true,[],"2026-07-22 04:02:09","\u003Cp align=\"center\">\n  \u003Cimg src=\"docs\u002Fassets\u002Flogo.png\" alt=\"Pawl logo — a ratchet wheel held by a pawl, with a checkmark at its center\" width=\"160\"\u002F>\n\u003C\u002Fp>\n\n\u003Ch1 align=\"center\">Pawl\u003C\u002Fh1>\n\n\u003Cp align=\"center\">\u003Cb>Registry-as-ground-truth verification & autonomous research framework for agent-driven development.\u003C\u002Fb>\u003C\u002Fp>\n\nCoding agents don't remember. Every new session starts blind: what was\nalready proven, what failed and why, which dead ends were closed for good —\ngone, buried in chat scrollback and stale plan documents. So agents re-try\nknown failures, re-explore settled questions, and report \"done\" for work\nthat no gate ever verified. Pawl fixes this by making progress itself a\nmachine-readable artifact: every meaningful change is a **claim** with\nacceptance gates frozen *before* implementation, a CSV **registry** — not\nplans, not dashboards, not memory of a conversation — records what is\nactually implemented, and failures are written down as **honest negatives**\nthat name the missing capability and permanently block the dead end. Like\nthe mechanism it is named after — the small catch that lets a ratchet\nwheel turn forward but never slip back — Pawl makes verified progress the\nonly direction the record can move. The origin project ran 590 claims\nthrough it in 18 days with 4–5 parallel agent sessions: 404 verified,\n167 honest negatives, zero corrupted records (see the\n[case study](#case-study-the-origin-project)).\n\nWorks for any kind of software project — web app, library, ML project,\nCLI tool. Pure Python standard library, zero dependencies: adopt it by\ncopying one folder and writing one small config file.\n\n## Why \"Pawl\"?\n\nA **pawl** is the small catch in a ratchet mechanism — the part that\nengages the teeth of a ratchet wheel and lets it turn forward one click at\na time, but blocks any backward slip. That is the whole metaphor: agent\nsessions should advance only on **verified** progress, and known dead ends\nshould stay closed instead of being re-explored every time someone opens a\nfresh chat.\n\nThe name is also a nod to\n[karpathy\u002Fautoresearch](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch) (March\n2026), which uses the same ratchet idea for a single training file: keep\nimprovements, discard regressions, one scalar, one budget. Pawl generalizes\nthat loop to a whole repository — many concurrent claims, per-claim edit\nscopes, a persistent dependency-linked registry, and **honest negatives\npromoted into the record** instead of silently reset away.\n\n## Shopware & Agentic Commerce Lab\n\nPawl is maintained and open-sourced by\n[**Agentic Commerce Lab**](https:\u002F\u002Fgithub.com\u002Fagentic-commerce-lab) —\n[Shopware](https:\u002F\u002Fwww.shopware.com\u002F)'s initiative for open protocols and\ndeveloper tooling at the intersection of AI agents and commerce\n([agentic-commerce.dev](https:\u002F\u002Fwww.agentic-commerce.dev\u002F)). The Lab's\nrepos — UCP, AXP, WebMCP, sales-agent harnesses, and related bridges —\nare built by parallel agent sessions where a false \"done\" is expensive.\nPawl is the **verification discipline** those sessions run on: not a\ncommerce protocol itself, but the registry-and-gates layer that keeps\nagent work honest in any codebase.\n\nIt was first battle-tested on\n[**Hylaean**](https:\u002F\u002Fwww.hylaean.ai\u002F) (the origin project below) and then\nextracted as a standalone, project-agnostic framework so other teams —\ninside Shopware, across the agentic-commerce ecosystem, or anywhere agents\nship code — can adopt the same ratchet without copying a whole research\nrepo.\n\n## The philosophy in five lines\n\n1. **No green verification → the feature is not implemented.** A merged PR,\n   a passing unit test, or a convincing demo is not \"done\" — a green claim\n   gate is.\n2. **Plans are proposals; the registry is ground truth.** Plans propose\n   claims; only registered, gated claims count.\n3. **Measurable success criteria come before implementation.** Gates are\n   frozen a priori — a gate defined after seeing the results is a\n   rationalization.\n4. **Honest negatives are first-class results.** A clean `Failed` with the\n   missing capability named is progress: it blocks the dead end for every\n   future session.\n5. **Failed triggers a downstream sweep.** Every Planned claim that depended\n   on a Failed one is immediately re-hung, re-scoped, or closed.\n\nConcretely, Pawl gives agents (a) a queryable memory of every attempt and\noutcome, (b) gates they cannot argue with, and (c) a loop for running\nexperiments unattended without corrupting the record.\n\n## How it works at a glance\n\n![Architecture: humans program the research org (big picture, rules, plans); the registry is ground truth feeding claim folders, the official runner, and the memory index; autoresearch runs the fast loop with promotion only via the runner](docs\u002Fassets\u002Farchitecture.svg)\n\n## What's in the box\n\n```text\npawl\u002F\n├── README.md                 # this file\n├── AGENTS.template.md        # agent entry point template (copy to repo root)\n├── docs\u002F                     # methodology\n│   ├── verification.md       # registry, claims, lifecycle, folder layout\n│   ├── autoresearch.md       # the autonomous research loop\n│   ├── big-picture-guide.md  # how to write the agent-facing project doc\n│   ├── plans.md              # plans as proposals; plan->claim linkage\n│   ├── tracks-and-fronts.md  # research fronts and success criteria\n│   ├── honest-negatives.md   # Failed as a first-class result\n│   ├── metric-integrity.md   # honest measurement discipline\n│   └── adoption.md           # step-by-step adoption guide\n├── templates\u002F                # big-picture, plan, claim README, contract,\n│                             # tracks.json, verify.json, CHANGELOG\n├── rules\u002F                    # portable .mdc rules -> your .cursor\u002Frules\u002F\n├── skills\u002F                   # portable skills    -> your .cursor\u002Fskills\u002F\n├── tools\u002F                    # the runnable layer (stdlib only)\n│   ├── init_project.py       # bootstrap verify.json + registry into a repo\n│   ├── register.py           # add a Planned claim (duplicate check, schema)\n│   ├── init_folder.py        # create the claim folder from the registry row\n│   ├── run.py                # official runner: gate -> Verified | Failed\n│   ├── scan.py               # audit, search, Planned triage\n│   ├── memory.py             # BM25 index over claims + plans (fronts, query, show)\n│   └── lib\u002F                  # config, ledger schema, locking\n├── autoresearch\u002F             # autonomous loop: program template + bootstrap\n└── examples\u002Fdemo-project\u002F    # a complete worked example (real runs)\n```\n\n## Quickstart (5 minutes)\n\n```bash\n# 0. Copy the pawl folder into your repo (or keep it as a sibling checkout).\n#    TOOLS below = path to pawl\u002Ftools.\n\n# 1. Bootstrap your project (creates verify.json, registry.csv, tracks.json):\ncd ~\u002Fmy-project\npython3 $TOOLS\u002Finit_project.py my-project --plans-dir docs\u002Fplans\n\n# 2. Register your first claim — a falsifiable sentence with thresholds:\npython3 $TOOLS\u002Fregister.py VERIFY.CORE.CSV_PARSER.01 \\\n  \"CSV parser handles quoted fields and CRLF; 12 fixture files round-trip \\\nbyte-identical; parse of 100k rows \u003C= 2 s on the fixed bench\"\n\n# 3. Create its folder (README + run.py skeleton):\npython3 $TOOLS\u002Finit_folder.py VERIFY.CORE.CSV_PARSER.01\n\n# 4. Freeze the gates in the generated run.py, THEN implement the feature.\n\n# 5. Official pass — writes Verified\u002FFailed back to the registry:\npython3 $TOOLS\u002Frun.py VERIFY.CORE.CSV_PARSER.01\n\n# 6. Query your project's memory:\npython3 $TOOLS\u002Fmemory.py fronts\npython3 $TOOLS\u002Fmemory.py query \"csv parser\"\npython3 $TOOLS\u002Fmemory.py show VERIFY.CORE.CSV_PARSER.01\n```\n\nA fully executed example lives in\n[`examples\u002Fdemo-project\u002F`](examples\u002Fdemo-project\u002F) — including one Verified\nclaim and one honest-negative Failed claim.\n\n## The claim lifecycle\n\n```text\nscan -> register.py (CSV row only) -> init_folder.py -> freeze gates\n     -> implement -> tools\u002Frun.py -> Verified | Failed\n```\n\n![Claim lifecycle: register creates Planned; the official runner promotes to Verified (exit 0) or Failed (exit 1, honest negative); Failed triggers the downstream sweep and can be superseded by a claim with a new capability; Planned can be closed with active=false](docs\u002Fassets\u002Fclaim-lifecycle.svg)\n\n| Exit code of the gate | Registry status | Meaning |\n|---|---|---|\n| 0 | `Verified` | Feature implemented (gates green) |\n| 1 | `Failed` | Honest negative — missing capability named |\n| — | `Planned` | Not yet run, or triage pending |\n| — (run lock busy) | unchanged | Gate never ran — another live session is running this claim; the runner skips it and exits non-zero |\n\n**No folder without a registry row.** Folder name is always\n`YYYY-MM-DD-NN-CLAIM_ID`. `scan.py --audit` enforces consistency.\n\n## The registry schema\n\n`registry.csv`, one row per claim:\n\n| Column | Content |\n|---|---|\n| `claim_id` | `VERIFY.\u003CFAMILY>.\u003CNAME>.\u003CNN>` (prefix configurable) |\n| `entry_id` | per-day sequence `YYYY-MM-DD-NN` |\n| `created` | registration date |\n| `claim` | full falsifiable text: what, thresholds, anti-patterns |\n| `status` | `Planned` \\| `Verified` \\| `Failed` \\| `In progress` |\n| `location` | `\u003Cverification_dir>\u002FYYYY-MM-DD-NN-CLAIM_ID` |\n| `dependencies` | other claim_ids (`;`-separated) or `-` |\n| `script` | the runnable gate (default `\u003Clocation>\u002Frun.py`) |\n| `scope` | code\u002Ftest paths this claim owns (`;`-separated) or `-` |\n| `supersedes` | claim replaced by this one, or empty |\n| `notes` | short human status line (verdict, close reason) |\n| `active` | `true` \\| `false` — only `true` counts operationally |\n\n## Autonomous research\n\nThe [`autoresearch\u002F`](autoresearch\u002F) layer turns the registry into an\nautonomous experiment loop: an agent picks a target claim, edits **only**\nthat claim's declared `scope`, measures against a **fixed harness** it may\nnot edit, commits scoped `keep`s or reverts `discard`s on main, and\npromotes only through the official runner. The human programs the research\norganization (rules, harness, program); the agent executes it.\nSee [`docs\u002Fautoresearch.md`](docs\u002Fautoresearch.md).\n\n![Autoresearch loop: pick a target, bootstrap the claim if missing, form one hypothesis inside the declared scope, measure against the fixed harness, keep (scoped commit) or discard (scoped revert), floor-check the full gate every few keeps, promote via the official runner or record an honest negative and sweep dependents](docs\u002Fassets\u002Fautoresearch-loop.svg)\n\nDiagram sources: [`docs\u002Fassets\u002Fsrc\u002F`](docs\u002Fassets\u002Fsrc\u002F) — regeneration:\n[`docs\u002Fassets\u002FREADME.md`](docs\u002Fassets\u002FREADME.md).\n\n## Adoption in 5 steps\n\n1. **Write the big picture** — the agent-facing project doc: mission,\n   one-sentence law, layers, anti-sprawl rules\n   ([`templates\u002Fbig-picture.template.md`](templates\u002Fbig-picture.template.md),\n   guide: [`docs\u002Fbig-picture-guide.md`](docs\u002Fbig-picture-guide.md)).\n2. **Define tracks** — group your claim families into research fronts with\n   success criteria ([`templates\u002Ftracks.template.json`](templates\u002Ftracks.template.json),\n   [`docs\u002Ftracks-and-fronts.md`](docs\u002Ftracks-and-fronts.md)).\n3. **Register the first claims** — `init_project.py`, then `register.py` +\n   `init_folder.py` for the 2–5 changes you actually care about next.\n4. **Copy rules and skills** — `rules\u002F*.mdc` → `.cursor\u002Frules\u002F`,\n   `skills\u002F*` → `.cursor\u002Fskills\u002F`, `AGENTS.template.md` → `AGENTS.md`;\n   replace the `\u003CPLACEHOLDERS>`.\n5. **Start the loop** — manual first (agent implements against frozen\n   gates), then autonomous\n   (`autoresearch\u002Fprogram.template.md`).\n\nFull guide: [`docs\u002Fadoption.md`](docs\u002Fadoption.md).\n\n## Companion systems: code memory\n\nPawl records **experimental memory** — what was tried, what the gates said,\nwhat is closed for good. Agent sessions lose a second kind of memory\nbetween runs: **structural memory** — how the code hangs together and what\nbreaks if you change it. The setup Pawl was extracted from pairs it with\ntwo codebase-memory systems, both equally project-agnostic and worth\nadopting alongside it:\n\n* **graphify** — a *committed* knowledge-graph snapshot of the repo\n  (`graphify-out\u002F`: `graph.json`, a generated `GRAPH_REPORT.md`, optional\n  wiki\u002FHTML export). A CLI answers structural questions offline and the\n  artifact travels with the repo: `graphify query \"\u003Cquestion>\"` (scoped\n  subgraph), `graphify path \"\u003CA>\" \"\u003CB>\"` (dependency path between two\n  symbols), `graphify explain \"\u003Cconcept>\"`, and `graphify update .` after\n  edits to keep the snapshot current. Because it is committed, reviewers\n  and CI see the same architecture picture the agent saw.\n* **codebase-memory-mcp** — a *live* local MCP server (a Go binary with a\n  persistent SQLite graph built from tree-sitter ASTs: qualified symbols,\n  call edges, HTTP edges) that auto-syncs in the background as files\n  change. Agents query it instead of grepping: `search_graph` (find\n  symbols by name or concept), `trace_path` (who calls X \u002F what does X\n  call), `get_architecture` (packages, hotspots, wiring), and\n  `detect_changes` (blast radius of the current git diff — what is\n  affected before you run anything).\n\nThe division of labor with Pawl is clean, and the combination is what makes\nagent sessions stop repeating themselves:\n\n| Question | System |\n|---|---|\n| \"How does the code hang together? What breaks if I change this?\" (**before the edit**) | code graph — `trace_path`, `detect_changes`, `graphify path` |\n| \"What was already tried and what came out?\" (**before the experiment**) | Pawl — `memory.py query \u002F show \u002F fronts` |\n| Exact string or config literal | plain grep |\n\nStructural memory keeps agents from re-exploring the codebase every\nsession; experimental memory keeps them from re-running settled\nexperiments. A practical convention from the origin setup: make the code\ngraph the *mandatory first step* for structural questions (a rule in\n`.cursor\u002Frules\u002F`), exactly like Pawl's memory query is mandatory before\nregistering a claim.\n\n## How is this different?\n\nThere is a wave of autonomous-loop and agentic-SWE tooling (as of mid-2026).\nPawl occupies a specific, mostly empty slot: **the bookkeeping and\nintegrity layer for agent-driven development in an existing repo** — not an\nagent, not a harness, not a tracker.\n\n| | [karpathy\u002Fautoresearch](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch) | [Sakana AI Scientist](https:\u002F\u002Fgithub.com\u002FSakanaAI\u002FAI-Scientist) | [SWE-agent](https:\u002F\u002Fgithub.com\u002FSWE-agent\u002FSWE-agent) \u002F [OpenHands](https:\u002F\u002Fgithub.com\u002FAll-Hands-AI\u002FOpenHands) | AutoGPT-style loops | MLflow \u002F W&B | **Pawl** |\n|---|---|---|---|---|---|---|\n| Goal | Improve one LLM training file overnight | Generate research papers end-to-end | Resolve issues \u002F write PRs | Open-ended task pursuit | Log ML experiment runs | Verified capability record for any repo |\n| Unit of work | One edit to `train.py` | One paper | One issue\u002FPR | One \"thought\u002Faction\" | One run | One **claim** with frozen gates |\n| Ground truth | git history + `results.tsv` | The generated paper | PR merged \u002F benchmark score | Chat history | Metrics DB (no verdicts) | **`registry.csv`** — statuses written only by the runner |\n| Success metric | Single scalar (`val_bpb`), fixed 5-min budget | Automated LLM reviewer score | SWE-bench \u002F tests | Self-assessed | User-defined, unenforced | Per-claim frozen thresholds + per-front authoritative scalar |\n| Negative results | Code reset; a line in local `results.tsv` | Not published | Closed\u002Ffailed run | Lost in scrollback | Just another run | **Failed = published first-class result**, blocks dead ends via dependency edges |\n| Edit boundaries | One file by construction | Template code | Whole repo | Whole system | n\u002Fa | Per-claim declared **`scope`** |\n| Memory across sessions | git log | None | None | Vector stores \u002F ad hoc | Run history | Queryable BM25 index over claims **and** plans, with dependency + supersedes edges |\n| Multi-agent safety | Single agent | Single pipeline | Sandboxed runs per task | Mostly single | n\u002Fa (shared backend) | Registry lock + per-claim run locks, stale-PID takeover |\n| Dependencies | PyTorch stack | Full ML stack | Docker + LLM stack | Varies | Client libs + tracking backend | **Python stdlib only** |\n\nProse, in a nutshell:\n\n* **vs. karpathy\u002Fautoresearch** (released March 2026; the closest relative\n  and an explicit inspiration — even for this project's name): Karpathy's\n  loop is a beautifully minimal ratchet — one file (`train.py`), one scalar\n  (`val_bpb`), a fixed 5-minute budget, keep on improvement or reset on\n  equal-or-worse. Pawl generalizes the ratchet to a whole repository: many\n  concurrent claims instead of one file, per-claim edit scopes instead of\n  \"everything in `train.py` is fair game\", and a persistent registry with\n  dependency edges instead of a local `results.tsv`. The biggest\n  philosophical difference: **negatives are promoted, not just logged**. In\n  the Karpathy loop a failed idea is reset away, surviving only as a line\n  in the local experiment log; here it becomes a `Failed` claim that names\n  the missing capability and permanently blocks the dead end. Shared core\n  conviction: *the human programs the research org* (his `program.md` ↔\n  Pawl's rules + program template).\n* **vs. Sakana AI Scientist**: that system automates *science-shaped\n  output* — idea generation, experiments inside provided code templates,\n  paper drafting, and an automated LLM peer review. Pawl automates no\n  science at all — it is the ledger and gate discipline that keeps\n  whatever agent you use honest while it works on *your* codebase.\n  (Independent evaluation of the AI Scientist also found it needs heavy\n  supervision — a large share of its experiments fail on execution — which\n  is precisely the failure mode a frozen external gate is built to catch.)\n* **vs. SWE-agent \u002F OpenHands**: those are the **agents** — SWE-agent\n  (Princeton) established the SWE-bench-style issue-resolution loop,\n  OpenHands (formerly OpenDevin) is the leading open-source agent platform.\n  They decide how to edit code; Pawl is the **ground-truth layer around any\n  agent**: what counts as done, what was already tried, what failed and\n  why. They compose: an OpenHands or Cursor session is a fine executor for\n  claims registered here.\n* **vs. MLflow \u002F W&B**: experiment trackers record what happened; they have\n  no notion of a falsifiable claim, a frozen gate, or a verdict that a\n  runner writes back to a ground-truth ledger. Tracking answers \"what were\n  the numbers?\" — a registry answers \"**is it implemented, and how do we\n  know?**\"\n\n## Case study: the origin project\n\n> This section names the origin project as provenance; everything else in\n> the framework is project-agnostic.\n\nPawl was extracted from **[Hylaean](https:\u002F\u002Fwww.hylaean.ai\u002F)**\n(the \"Field AI\" research repo) — an AI-research codebase where essentially\nall implementation work is done by parallel agent sessions, and where a\nwrong \"it works\" is far more expensive than a slow one. The numbers below\nare counted live from that repo's registry (2026-07-13), not estimated:\n\n* **590 claims registered in 18 days** (2026-06-26 → 2026-07-13), spanning\n  57 claim families curated into 10 tracks.\n* Of the 588 active claims: **404 Verified, 167 Failed, 17 Planned** —\n  a 28% honest-negative rate, every Failed row naming its missing\n  capability.\n* **45 plan documents** linked to claims by the memory index (~770\n  plan→claim edges) — plans proposed the work; only the registry says what\n  landed.\n* **4–5 parallel agent sessions** on one host, coordinated through the\n  registry lock and per-claim run locks — zero registry corruption and no\n  duplicated official runs over the whole period.\n\nWhat the discipline bought, concretely:\n\n* **Dead ends closed once, permanently.** A single census wave measured\n  eight candidate \"breakthrough\" directions against pre-frozen kill rules\n  and closed all eight *before any of them was built* — honest negatives\n  that saved months. A separately tempting 88-task shortcut was measured\n  to zero in five independent attempts and is terminal-negative: reopening\n  is locked behind two named missing primitives.\n* **Regressions caught before merge.** A verified baseline lock freezes\n  every solved benchmark task by ID; any change that regresses one solve\n  or introduces one false result fails verification before it lands\n  (re-locked stepwise from 94 to 145 tasks as capability grew).\n* **Honest public accounting.** The project publishes its status log —\n  including the negatives — straight from the registry\n  ([hylaean.ai](https:\u002F\u002Fwww.hylaean.ai\u002F)); its front page reports an\n  *unsolved* headline benchmark (0\u002F120 eval) next to its verified wins,\n  because the registry, not the marketing, is the source of truth.\n* **Memory that survives sessions.** New agent sessions start with\n  `memory.py fronts` \u002F `query` instead of re-reading hundreds of folders —\n  the duplicate check before registering is what keeps 590 claims from\n  becoming 900 redundant ones.\n\n## Design decisions\n\n- **CSV + JSON + Markdown, stdlib only.** Diffs are reviewable, merges are\n  resolvable, and there is nothing to install. That is deliberate: the\n  framework must be more durable than any toolchain fashion.\n- **Registry locking is portable.** Lock-file with stale-PID takeover +\n  atomic replace — safe for parallel agent sessions on one machine without\n  OS-specific APIs.\n- **The memory index is generated and gitignored.** It rebuilds in well\n  under a second for hundreds of claims; committing it would only create\n  merge noise.\n- **`_template\u002F` folder over generators where possible.** Projects customize\n  the claim skeleton by editing files, not code.\n- **The config file stays `verify.json`.** It describes function, not\n  brand — an adopting repo's root should explain itself to someone who has\n  never heard of Pawl.\n\n## Provenance\n\nMaintained by\n[Agentic Commerce Lab](https:\u002F\u002Fgithub.com\u002Fagentic-commerce-lab)\n(Shopware). Extracted and generalized from the origin project described\nin the case study above. The autonomous-loop design is inspired in part by\n[karpathy\u002Fautoresearch](https:\u002F\u002Fgithub.com\u002Fkarpathy\u002Fautoresearch), extended\nwith per-claim scopes, a persistent dependency-linked registry, and honest\nnegatives as first-class results.\n","Pawl 是一个面向智能体驱动开发的自主研究与可信验证框架，通过将进展建模为机器可读的声明（claims）并持久化到 CSV 注册表中，实现基于事实的进度追踪与失败归因。其核心特点是采用‘注册表即真相’（registry-as-ground-truth）机制，强制每个变更附带预定义验收门、明确记录已验证成果与‘诚实否定’（honest negatives），杜绝重复探索已知死路；纯 Python 实现，零外部依赖，仅需复制单个文件夹并配置即可集成。适用于多智能体协同开发场景，尤其适合需要高可信度交付的 Web 应用、ML 工程、CLI 工具等软件项目。",2,"2026-07-18 02:30:05","CREATED_QUERY"]