@ethan.carter/autocode 0.0.0-stage → 0.0.1

package/dist/chunk-TK24OTGL.js

@@ -0,0 +1,3 @@
+import{q as T}from"./chunk-WWJJMIQL.js";import"./chunk-KKQQYXWN.js";import"./chunk-7LS5USHJ.js";import{g as y,k as R,m as g,n as O,r as b,t as A}from"./chunk-CBLU2NBO.js";import{a as r}from"./chunk-XUSV3KOD.js";import{readFile as E,readdir as L}from"node:fs/promises";import m from"node:path";import{parse as M}from"yaml";var q=/^\s+- <a id="[^"]+"><\/a>(.*?) → `([^`]+)` · (\S+?)(?::\d+)?$/,z=/^### \S+?\.rule\.[a-z0-9][a-z0-9-]* · (.+)$/,C=/^---\r?\n([\s\S]*?)\r?\n---\r?\n?([\s\S]*)$/;async function K(e,t="zh"){let i=m.join(e,y),a=await k(i),o=await B(i),D=await J(i),x=r(s=>{let{file:f,name:u}=_(s);if(f)return f;let c=o.get(u);return a.get(u)?.file??(c&&c.size===1?[...c][0]:void 0)},"fileOf"),F=(await T(e)).map(s=>({term:s.term,module:s.module,kind:s.kind,status:s.status,aliases:s.aliases,files:h(s.anchors.map(x))})),N=[];for(let[s,f]of[[g,"unit"],[O,"domain"]]){let u;try{u=(await L(m.join(i,s))).filter(c=>c.endsWith(".md")).sort()}catch{continue}for(let c of u){let $=await E(m.join(i,s,c),"utf8"),w=C.exec($),S=w?.[2]??$,l={};try{l=(w?M(w[1]):null)??{}}catch{}let p=[...d([l.entry]),...d(l.entries)];if(f==="unit"&&p.some(n=>D.has(n)))continue;let I=d(l.anchors),j=p.map(n=>a.get(n)?.label).filter(n=>!!n);N.push({path:`${y}/${s}/${c}`,layer:f,title:/^#\s+(.+)$/m.exec(S)?.[1]?.trim()??c.replace(/\.md$/,""),summary:/^>\s+(.+)$/m.exec(S)?.[1]?.trim()??"",...typeof l.confidence=="number"?{confidence:l.confidence}:{},up:d(l.up).map(n=>`${y}/${n}`),names:h([...p,...I.map(n=>_(n).name),...j.flatMap(U)]),files:h([...p,...I].map(x)),terms:d(l.terms),rules:f==="domain"?S.split(`
+`).map(n=>z.exec(n.trimEnd())?.[1]?.trim()).filter(n=>!!n):[]})}}return{terms:F,documents:N,language:t}}r(K,"readCatalog");function _(e){let t=e.indexOf("::");return t>0&&/[\\/]/.test(e.slice(0,t))?{file:e.slice(0,t),name:e.slice(t+2)}:{name:e}}r(_,"splitAnchor");function U(e){let t=/^[A-Z]+\s+(\/\S+)$/.exec(e.trim());return t?[e.trim(),t[1]]:[e.trim()]}r(U,"routeNames");async function k(e){let t=new Map,i;try{i=await E(m.join(e,b),"utf8")}catch{return t}for(let a of i.split(`
+`)){let o=q.exec(a.trimEnd());o&&t.set(o[2],{label:o[1].trim(),file:o[3]})}return t}r(k,"readEntryCatalog");async function B(e){let t=new Map;try{let i=JSON.parse(await E(m.join(e,R),"utf8"));for(let a of i.symbols??[]){let o=t.get(a.qualifiedName);o?o.add(a.file):t.set(a.qualifiedName,new Set([a.file]))}}catch{}return t}r(B,"readSymbolFiles");async function J(e){try{let t=JSON.parse(await E(m.join(e,A),"utf8"));return new Set((t.excludedEntries??[]).map(i=>i.qualifiedName))}catch{return new Set}}r(J,"readExcludedEntries");function d(e){return Array.isArray(e)?e.filter(t=>typeof t=="string"&&t.length>0):[]}r(d,"strings");function h(e){return[...new Set(e.filter(t=>!!t))]}r(h,"unique");export{K as readCatalog,_ as splitAnchor};

package/dist/chunk-UCR2PGFQ.js

@@ -0,0 +1 @@
+import{j as e,m as f,n as g}from"./chunk-ZXRDZ4KX.js";import{a,b}from"./chunk-BD2OOWDK.js";import{c as d}from"./chunk-7LS5USHJ.js";import{d as c}from"./chunk-MHDSNQAC.js";import"./chunk-CBLU2NBO.js";import"./chunk-XUSV3KOD.js";export{c as captures,g as findWorkspaceRoot,d as logs,b as openStateDb,f as runs,a as stateDbPath,e as tasks};

package/dist/chunk-WWJJMIQL.js

@@ -0,0 +1,4 @@
+import{e as L}from"./chunk-KKQQYXWN.js";import{H as O,g as A,q as $}from"./chunk-CBLU2NBO.js";import{a as i}from"./chunk-XUSV3KOD.js";import{z as u}from"zod";import{AsyncLocalStorage as Y}from"node:async_hooks";import{z as b}from"zod";var _=new Y;async function ot(t){let e=[];return{result:await _.run(e,t),coercions:e}}i(ot,"collectCoercions");function N(t){return t===null?"null":Array.isArray(t)?"array":typeof t}i(N,"kindOf");function j(t,e,n){_.getStore()?.push({path:t.path.join("."),from:N(e),to:n})}i(j,"record");function y(){let t=b.array(b.string());return b.preprocess((e,n)=>e==null?(e===null&&j(n,e,"array"),[]):typeof e=="string"?(j(n,e,"array"),e.trim()===""?[]:[e]):e,t)}i(y,"stringList");function M(t){let e=b.string();return b.preprocess((n,s)=>n??(n===null&&j(s,n,"string"),t),e)}i(M,"textOr");function rt(t){return b.preprocess((e,n)=>e??(e===null&&j(n,e,"array"),[]),t)}i(rt,"listOr");function it(t,e){return b.preprocess((n,s)=>{if(typeof n!="object"||n===null||Array.isArray(n))return n;let r={...n};return e(r,(o,f)=>_.getStore()?.push({path:[...s.path,o].join("."),from:N(n[o]),to:f})),r},t)}i(it,"patched");var w=["object","state","event","action"],ut=u.object({module:u.string().optional().describe("leave empty: the term belongs to this task's module. Name another module ONLY when the concept clearly belongs there by the module guide (it owns the object's lifecycle, or the term's anchors sit in that module's code location) \u2014 it must be one of the listed modules; an unlisted module is rejected, raise a question instead"),kind:u.enum(w).describe("exactly one of: object (what the system manages, with attributes and relations) / state (the situation an object is in; names its object) / event (a fact that has happened; may move an object between states) / action (what the system does). No other kind exists: whoever triggers the system (a user, a role, a scheduler, a third-party platform) is not a term \u2014 the action it triggers is; a policy is a rule not a term; UI behaviour is not a term"),term:u.string().min(1).describe("the term, one concept one name, unique within the module"),definition:u.string().min(1).describe("one-line definition in the reader's business language"),aliases:y().describe("other names seen in code or conversation; retrieval only"),object:M("").describe("for state (required) and event (optional): the object this belongs to, declared in this module; empty otherwise"),relations:y().default([]).describe("for object only: other objects of this module it holds or refers to (declared term names); empty otherwise"),effects:y().default([]).describe("for action only: events (declared term names) this action produces; empty otherwise"),side_effects:y().default([]).describe("for action only: effects leaving the system boundary \u2014 an external call, a message sent, a file written \u2014 in plain words; empty otherwise"),transitions:u.object({from:u.string().describe("the state the object leaves; empty string when it is the initial transition"),to:u.string().min(1).describe("the state the object enters (must be declared for the same object)")}).nullable().default(null).describe("for event only: which state change it causes; null when the event changes no state and for every other kind"),anchors:u.array(u.string()).min(1).describe("qualifiedNames of the code symbols carrying this concept, copied VERBATIM from the symbol map \u2014 at least one, never a file path")});import{mkdir as U,readFile as D,writeFile as z}from"node:fs/promises";import T from"node:path";function gt(t,e){return{module:e,kind:t.kind,term:t.term,definition:t.definition,aliases:t.aliases,object:t.object,relations:t.relations,effects:t.effects,sideEffects:t.side_effects,transitions:t.transitions,anchors:t.anchors,status:"pending"}}i(gt,"termFromPayload");function x(t){return`${t.module}.${t.kind}.${t.term}`}i(x,"termKey");var v={entity:"object","value-object":"object",command:"action",event:"event",state:"state"},F={zh:"# \u4E1A\u52A1\u672F\u8BED",en:"# Business terms"},q={zh:"| \u72B6\u6001 | \u7C7B\u578B | \u672F\u8BED | \u5B9A\u4E49 | \u522B\u540D | \u6240\u5C5E\u5BF9\u8C61 | \u5173\u7CFB | \u6D41\u8F6C / \u6548\u679C | \u526F\u4F5C\u7528 | \u951A\u70B9 | \u540C\u540D\u4E8E |",en:"| Status | Kind | Term | Definition | Aliases | Object | Relations | Transition / Effects | Side effects | Anchors | Same name in |"},P="|---|---|---|---|---|---|---|---|---|---|---|",R={zh:{pending:"\u5F85\u786E\u8BA4",confirmed:"\u5DF2\u786E\u8BA4"},en:{pending:"pending",confirmed:"confirmed"}},V=new Map(Object.values(R).flatMap(t=>Object.entries(t).map(([e,n])=>[n.toLowerCase(),e]))),I=new Map(w.map((t,e)=>[t,e])),B={zh:{object:"\u5BF9\u8C61",state:"\u72B6\u6001",event:"\u4E8B\u4EF6",action:"\u52A8\u4F5C"},en:{object:"Object",state:"State",event:"Event",action:"Action"}},G={\u5B9E\u4F53:"entity",\u503C\u5BF9\u8C61:"value-object",\u547D\u4EE4:"command",\u4E8B\u4EF6:"event",\u72B6\u6001:"state",Entity:"entity","Value object":"value-object",Command:"command",Event:"event",State:"state"},K=new Map([...Object.values(B).flatMap(t=>Object.entries(t).map(([e,n])=>[n,e])),...w.map(t=>[t,t]),...Object.entries(G).map(([t,e])=>[t,v[e]]),...Object.entries(v).map(([t,e])=>[t,e])]),H=new Set(["\u53C2\u4E0E\u8005","Actor","actor"]),yt=new Set([...H,...Object.keys(G).filter(t=>!["\u4E8B\u4EF6","\u72B6\u6001","Event","State"].includes(t)),"entity","value-object","command"]);function W(t,e){return B[e][t]??t}i(W,"kindLabel");var l=i(t=>t.replaceAll("|","\\|").replaceAll(/\r?\n/g," ").trim(),"cell"),p=i(t=>t.replaceAll("\\|","|").trim(),"uncell"),S=i(t=>t===void 0||t==="\u2014"?"":p(t),"dash"),h=i(t=>S(t).split("\u3001").map(e=>e.trim()).filter(Boolean),"list");function X(t){return t.split(/(?<!\\)\|/).map(e=>e.trim())}i(X,"splitRow");function E(t){return t.object}i(E,"ownerOf");function J(t){return t.kind==="event"?t.transitions?`${t.transitions.from||"\u2205"} \u2192 ${t.transitions.to}`:"":t.kind==="action"?t.effects.join("\u3001"):""}i(J,"changeOf");function Q(t,e,n={}){let s=new Map((n.moduleOrder??[]).map((a,d)=>[a,d])),r=i(a=>s.get(a)??Number.MAX_SAFE_INTEGER,"rank"),o=new Map;for(let a of t)(o.get(a.term)??o.set(a.term,new Set).get(a.term)).add(a.module);let f=i(a=>[...o.get(a.term)??[]].filter(d=>d!==a.module).sort().join("\u3001"),"sameNameIn"),c=[...t].sort((a,d)=>r(a.module)-r(d.module)||a.module.localeCompare(d.module)||(I.get(a.kind)??99)-(I.get(d.kind)??99)||E(a).localeCompare(E(d))||a.term.localeCompare(d.term)),m=[F[e],""],g=null;for(let a of c)a.module!==g&&(g!==null&&m.push(""),g=a.module,m.push(`## ${g}`,"",q[e],P)),m.push(`| ${R[e][a.status]} | ${W(a.kind,e)} | ${l(a.term)} | ${l(a.definition)} | ${l(a.aliases.join("\u3001"))||"\u2014"} | ${l(E(a))||"\u2014"} | ${l(a.relations.join("\u3001"))||"\u2014"} | ${l(J(a))||"\u2014"} | ${l(a.sideEffects.join("\u3001"))||"\u2014"} | ${l(a.anchors.join("\u3001"))||"\u2014"} | ${l(f(a))||"\u2014"} |`);return m.push(""),m.join(`
+`)}i(Q,"renderGlossary");function C(t){let e=S(t),n=/^(.*?)\s*→\s*(.+)$/.exec(e);return n?{from:n[1]==="\u2205"?"":n[1].trim(),to:n[2].trim()}:null}i(C,"parseTransition");var k=i((t,e,n,s)=>({module:t,kind:e,term:n,definition:s,aliases:[],object:"",relations:[],effects:[],sideEffects:[],transitions:null,anchors:[],status:"pending"}),"EMPTY_TERM");function Z(t){let e=[],n="";for(let s of t.split(`
+`)){let r=/^## (.+)$/.exec(s);if(r){n=r[1].trim();continue}if(!s.trim().startsWith("|"))continue;let o=X(s);if(o[1]==="\u72B6\u6001"&&o[2]==="\u7C7B\u578B"||o[1]==="Status"&&o[2]==="Kind")continue;let f="pending";o.length===13&&(f=V.get((o[1]??"").toLowerCase())??"pending",o=[o[0],...o.slice(2)]);let c=o[1]??"";if(c===""||c.startsWith("-")||c==="\u7C7B\u578B"||c==="Kind"||c==="\u672F\u8BED"||c==="Term")continue;let m=e.length;tt(o,c,n,e);for(let g of e.slice(m))g.status=f}return e}i(Z,"parseGlossary");function tt(t,e,n,s){if(t.length===12){let r=K.get(e);if(!r)return;let o=k(n,r,p(t[2]),p(t[3]));o.aliases=h(t[4]),r!=="action"&&(o.object=S(t[5])),o.relations=h(t[6]),r==="event"&&(o.transitions=C(t[7])),r==="action"&&(o.effects=h(t[7])),o.sideEffects=h(t[8]),o.anchors=h(t[9]),s.push(o);return}if(t.length===9||t.length===10){let r=K.get(e);if(!r)return;let o=k(n,r,p(t[2]),p(t[3]));o.aliases=h(t[4]);let f=S(t[5]);(r==="state"||r==="event")&&(o.object=f),r==="event"&&(o.transitions=C(t[6])),o.anchors=h(t[7]),s.push(o);return}if(t.length===6){let r=k(p(t[4])||n,"object",p(e),p(t[2]));r.aliases=h(t[3]),s.push(r)}}i(tt,"parseRow");async function jt(t){try{return Z(await D(T.join(t,A,$),"utf8"))}catch{return[]}}i(jt,"readGlossaryTerms");function wt(t,e){let n=new Map;for(let s of t)n.set(x(s),{...s});for(let s of e){let r=x(s),o=n.get(r);if(o?.status==="confirmed"){o.definition!==s.definition&&L("glossary.confirmed-kept",{key:r,proposed:s.definition});continue}n.set(r,{...s,status:"pending",aliases:[...new Set([...o?.aliases??[],...s.aliases])],anchors:[...new Set([...o?.anchors??[],...s.anchors])]})}return[...n.values()]}i(wt,"mergeTerms");function Et(t,e){return t.filter(n=>n.module===e)}i(Et,"termsOfModule");function xt(t){return t.length===0?"":t.map(e=>{let n=E(e);return`- ${e.status==="confirmed"?"[\u5DF2\u786E\u8BA4 / confirmed] ":""}${x(e)}${n?`(${n})`:""}:${e.definition}`}).join(`
+`)}i(xt,"formatExistingTerms");async function St(t,e,n,s={}){let r=`${A}/${$}`,o=T.join(t,r),f=Q(e,n,s),c=null;try{c=await D(o,"utf8")}catch{}return c!==null&&O(c)===O(f)?{written:!1}:(await U(T.dirname(o),{recursive:!0}),await z(o,f,"utf8"),{written:!0,change:{path:r,action:c===null?"added":"updated",summary:`\u4E1A\u52A1\u672F\u8BED ${e.length} \u6761(\u5DF2\u786E\u8BA4 ${e.filter(m=>m.status==="confirmed").length})`}})}i(St,"persistGlossary");function At(t,e,n){return t.filter(s=>{let r=x({module:s.module||e,kind:s.kind,term:s.term});return n.has(r)?(L("glossary.confirmed-kept",{key:r,in:"patch"}),!1):!0})}i(At,"withoutConfirmed");export{ot as a,y as b,M as c,rt as d,it as e,w as f,ut as g,gt as h,x as i,v as j,V as k,H as l,yt as m,W as n,Q as o,Z as p,jt as q,wt as r,Et as s,xt as t,St as u,At as v};

package/dist/chunk-XUSV3KOD.js

@@ -0,0 +1 @@
+var d=Object.defineProperty;var e=(b,a)=>d(b,"name",{value:a,configurable:!0});var f=(b,a)=>{for(var c in a)d(b,c,{get:a[c],enumerable:!0})};export{e as a,f as b};

package/dist/chunk-Z7PLBHDY.js

@@ -0,0 +1,6 @@
+import{a as d,b as h}from"./chunk-G3XA757G.js";import{a as f,b as g,c as $}from"./chunk-OP2B3OCA.js";import{A as m,C as y}from"./chunk-CBLU2NBO.js";import{a as c}from"./chunk-XUSV3KOD.js";function p(s,a,r,l){let i=c((e,t)=>r(e,t),"t"),u=l.changeDocs??[];return s.empty?d([{key:"result",lines:[l.emptyGuidance]},{key:"terms",lines:[]},{key:"rules",lines:[]},{key:"documents",lines:[]},{key:"anchors",lines:[]},{key:"changeDocs",lines:[]},{key:"next",lines:[`- ${i("agent.query.next")}`]}],a):d([{key:"result",lines:[i("agent.query.result",{terms:s.terms.length,rules:(s.rules??[]).length,documents:s.documents.length,entries:(s.entries??[]).length,anchors:s.anchors.length,changeDocs:u.length})]},{key:"terms",lines:s.terms.map(e=>`- ${e.term}(${e.module} \xB7 ${l.kindLabel(e.kind)}):${e.definition}`)},{key:"rules",lines:(s.rules??[]).map(e=>`- ${e.id} \xB7 ${e.name} \xB7 ${e.domain} \xB7 ${h(e.path)}`)},{key:"documents",lines:s.documents.flatMap(e=>{let t=[i(`agent.query.layer.${e.layer??e.kind}`),...e.confidence!==void 0?[i("agent.query.confidence",{value:e.confidence.toFixed(2)})]:[],...e.anchorHit?[i("agent.query.anchorHit")]:[],h(e.path),e.title,...e.summary?[e.summary]:[]].join(" \xB7 "),o=e.up||e.down?[`  ${i("agent.query.links",{up:(e.up??[]).join("\u3001")||"\u2014",down:(e.down??[]).join("\u3001")||"\u2014"})}`]:[];return[`- ${t}`,...o]})},{key:"anchors",lines:[...(s.entries??[]).map(e=>`- ${i("agent.query.entry",{anchor:e.anchor,label:e.label,location:h(e.location),fragment:e.fragment,unit:e.unit})}${e.written?"":i("agent.query.unitMissing")}`),...s.anchors.map(e=>`- ${e.qualifiedName} \xB7 ${h(e.location)}`)]},{key:"changeDocs",lines:u.map(e=>`- ${e.id} \xB7 ${e.title} \xB7 ${e.status} \xB7 v${e.version} \xB7 ${h(e.path)}`)},{key:"next",lines:[`- ${i("agent.query.next")}`]}],a)}c(p,"renderQuery");async function C(s,a,r){let l=$(!!s.json,!!r.stdout.isTTY),i=await import("./chunk-TCHTUSVC.js"),u=(await i.loadConfig(r.cwd()).catch(()=>null))?.language??"zh",e=i.translator(u);if(!a||a.trim().length===0)return r.stderr.write(e("cli.usage.query")+`
+`),2;let t=await i.runQuery(r.cwd(),a);if(l==="json")return r.stdout.write(g(f("query",{data:t.empty?{empty:!0,guidance:i.EMPTY_GUIDANCE}:{keyword:t.keyword,terms:t.terms,rules:t.rules,documents:t.documents,entries:t.entries,anchors:t.anchors,changeDocs:t.changeDocs}}))+`
+`),0;if(l==="plain")return r.stdout.write(p(t,u,e,{emptyGuidance:i.EMPTY_GUIDANCE,kindLabel:c(n=>i.kindLabel(n,u),"kindLabel"),changeDocs:t.changeDocs})),0;if(t.empty)return r.stdout.write(i.EMPTY_GUIDANCE+`
+`),0;let o=[];if(t.terms.length>0){o.push(e("query.terms"));for(let n of t.terms)o.push(`  \u3010${n.term}\u3011(${n.module}\xB7${i.kindLabel(n.kind,u)}):${n.definition}`)}if(t.documents.length>0){o.push(e("query.documents"));for(let n of t.documents){let k=n.confidence!==void 0?`  [${n.confidence.toFixed(2)}]`:"";o.push(`  ${n.path}  ${n.title}${k}${n.summary?` \u2014\u2014 ${n.summary}`:""}`),(n.up||n.down)&&o.push(`    \u2191 ${(n.up??[]).join("\u3001")||"\u2014"}  \u2193 ${(n.down??[]).join("\u3001")||"\u2014"}`)}}for(let n of t.entries)o.push(`  ${n.label} \u2192 ${n.anchor}  ${n.location}  ${n.fragment}  ${n.unit}${n.written?"":e("agent.query.unitMissing")}`);if(t.anchors.length>0){o.push(e("query.anchors"));for(let n of t.anchors)o.push(`  ${n.qualifiedName}  ${n.location}`)}return o.length===0&&o.push(e("query.noHit",{keyword:a})),r.stdout.write(o.join(`
+`)+`
+`),0}c(C,"runQueryCommand");export{C as runQueryCommand};

package/dist/chunk-ZXRDZ4KX.js

@@ -0,0 +1,6 @@
+import{J as _,K as S,g as i,h as f,m as R,n as m,o as T}from"./chunk-CBLU2NBO.js";import{a as e,b as E}from"./chunk-XUSV3KOD.js";var D={};E(D,{claim:()=>l,claimById:()=>x,complete:()=>k,defer:()=>N,enqueue:()=>g,fail:()=>A,listByRun:()=>W,resetRunning:()=>y,resetTask:()=>U,skip:()=>O});function o(){return new Date().toISOString()}e(o,"now");function g(t,n,r){let s=t.connection.prepare("INSERT INTO tasks (id, run_id, type, target, status, updated_at) VALUES (?, ?, ?, ?, 'pending', ?)"),d=[];for(let p of r){let c=S();s.run(c,n,p.type,p.target,o()),d.push(c)}return d}e(g,"enqueue");function u(t){return{id:t.id,runId:t.run_id,type:t.type,target:t.target,status:t.status,cost:t.cost,durationMs:t.duration_ms,error:t.error??void 0}}e(u,"toRecord");function l(t,n){let r=t.connection.prepare(`UPDATE tasks SET status = 'running', updated_at = ?
+       WHERE id = (SELECT id FROM tasks WHERE run_id = ? AND status = 'pending' ORDER BY rowid LIMIT 1)
+         AND status = 'pending'
+       RETURNING *`).get(o(),n);return r?u(r):void 0}e(l,"claim");function x(t,n){let r=t.connection.prepare(`UPDATE tasks SET status = 'running', updated_at = ?
+       WHERE id = ? AND status = 'pending'
+       RETURNING *`).get(o(),n);return r?u(r):void 0}e(x,"claimById");function k(t,n,r){t.connection.prepare("UPDATE tasks SET status = 'done', cost = ?, duration_ms = ?, updated_at = ? WHERE id = ?").run(r.cost,r.durationMs,o(),n)}e(k,"complete");function A(t,n,r,s){t.connection.prepare("UPDATE tasks SET status = 'failed', error = ?, raw_output = ?, updated_at = ? WHERE id = ?").run(r,s??null,o(),n)}e(A,"fail");function O(t,n){t.connection.prepare("UPDATE tasks SET status = 'skipped', updated_at = ? WHERE id = ?").run(o(),n)}e(O,"skip");function N(t,n){t.connection.prepare("UPDATE tasks SET status = 'deferred', updated_at = ? WHERE id = ?").run(o(),n)}e(N,"defer");function U(t,n){t.connection.prepare("UPDATE tasks SET status = 'pending', error = NULL, updated_at = ? WHERE id = ?").run(o(),n)}e(U,"resetTask");function y(t){t.connection.prepare("UPDATE tasks SET status = 'pending', updated_at = ? WHERE status = 'running'").run(o())}e(y,"resetRunning");function W(t,n){return t.connection.prepare("SELECT * FROM tasks WHERE run_id = ? ORDER BY rowid").all(n).map(u)}e(W,"listByRun");var I={};E(I,{createRun:()=>w,finishRun:()=>H,getRun:()=>L,listFailures:()=>P});function w(t,n){let r=_();return t.connection.prepare("INSERT INTO runs (id, started_at, mode) VALUES (?, ?, ?)").run(r,new Date().toISOString(),n),r}e(w,"createRun");function H(t,n,r){t.connection.prepare("UPDATE runs SET finished_at = ?, summary_json = ? WHERE id = ?").run(new Date().toISOString(),JSON.stringify(r),n)}e(H,"finishRun");function L(t,n){let r=t.connection.prepare("SELECT * FROM runs WHERE id = ?").get(n);if(r)return{id:r.id,startedAt:r.started_at,finishedAt:r.finished_at,mode:r.mode,summary:r.summary_json===null?void 0:JSON.parse(r.summary_json),reported:r.reported===1}}e(L,"getRun");function P(t,n){return t.connection.prepare("SELECT id, target, error, raw_output FROM tasks WHERE run_id = ? AND status = 'failed' ORDER BY rowid").all(n).map(s=>({taskId:s.id,target:s.target,error:s.error??"",rawOutput:s.raw_output}))}e(P,"listFailures");import{access as h,mkdir as F}from"node:fs/promises";import a from"node:path";var M=[R,m,T];async function C(t){let n=a.resolve(t);for(;;){if(await j(n))return n;let r=a.dirname(n);if(r===n)return null;n=r}}e(C,"findWorkspaceRoot");async function j(t){try{return await h(a.join(t,i,f)),!0}catch{return!1}}e(j,"isInitialized");async function q(t){for(let n of M)await F(a.join(t,i,n),{recursive:!0})}e(q,"ensureLayout");export{g as a,x as b,k as c,A as d,O as e,N as f,U as g,y as h,W as i,D as j,w as k,H as l,I as m,C as n,j as o,q as p};

package/dist/hosts/templates/en/commands/auto-check.ejs

@@ -0,0 +1,25 @@
+---
+description: Health-check the knowledge base - stale anchors, orphans, frontmatter, host file versions, tech debt (zero AI)
+argument-hint: "[scope]"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep
+<% } -%>
+autocode-template: 1
+---
+
+# /auto-check
+
+## Run
+From the project root, with the Bash tool and a timeout of at least <%= timeoutMinutes %> minutes; never use inline `!` execution:
+    autocode check "$ARGUMENTS"
+(Pass no quotes when there is no argument.)
+
+## Relay
+The output is sectioned Markdown grouped High / Medium / Low. Relay it as is; do not embellish or add conclusions the engine did not state.
+- `host-outdated` means a host-side file is missing or behind; suggest the user run `autocode install`.
+- "not initialised" → suggest /auto-init.
+
+## Never
+- Never create or edit anything under `.autocode/`; it is generated.
+- Never answer the engine's questions on the user's behalf.
+- Never decompose the work yourself or bypass the command to edit documents; the workflow lives in the engine.

package/dist/hosts/templates/en/commands/auto-feat.ejs

@@ -0,0 +1,69 @@
+---
+description: Locate the original requirement (pasted text / URL / work item / file), produce the requirement restated in this project's business terms plus an implementation plan, for review and confirmation; implements the plan once the knowledge base reaches the development threshold and the user agrees
+argument-hint: "<what to build, or where the source is: pasted text / URL / work item / file>"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep, Edit, WebFetch, mcp__*
+<% } -%>
+autocode-template: 3
+---
+
+# /auto-feat
+
+## Step 1: locate the original requirement document
+`$ARGUMENTS` is what the user said, not necessarily the requirement itself. Decide where the source is, in this order, and stop at the first hit:
+1. The user pasted the requirement into the conversation → that is the source; take it verbatim, never rewrite or summarise.
+2. The user gave a URL → fetch the page body with the web-fetch tool.
+3. The user refers to a work item in a project tool (Feishu Project, Jira, ...) → fetch title, description and acceptance criteria with the matching MCP tool.
+4. The user refers to a file in the repo → Read it.
+5. None of the above → the user's words are the source; append the relevant background, goals, known files and constraints from the conversation, each marked "from conversation".
+Put one source comment on the first line of the text: `<!-- autocode-source: conversation|url|mcp|file|prompt <reference> -->`.
+When fetching the source:
+- Feishu / Lark document links (`/wiki/`, `/docx/`) cannot be web-fetched: use lark-cli or a Feishu MCP when available to get the Markdown body, and download the images in it.
+- Pages behind a login or rendered by scripts: use a browser automation tool when available.
+- PDF: Read it directly (images and CJK PDFs included); do not use extraction tools such as pdftotext.
+- Images, interface documents and other material the source refers to are not pasted into it: put them in a scratch folder inside the repo (not under `.autocode/`) and hand it over with `--attachments` in step 2. The engine keeps a copy in the change folder; the scratch folder can go afterwards.
+
+## Step 2: run (source goes through stdin)
+    autocode feat "$ARGUMENTS" <<'AUTOCODE_ORIGINAL'
+    <source text>
+    AUTOCODE_ORIGINAL
+Bash tool, timeout of at least <%= timeoutMinutes %> minutes. The source always goes through stdin, never into the argument.
+- Material to hand over: add `--attachments <scratch folder>`.
+- The user says "no plan yet" / "just the restatement": add `--no-plan` and read only the integrate document in step 3; when the user wants the plan later, run `autocode feat --plan-only <document id>` (plans from the existing restatement, reads no stdin).
+The "Result" section gives the folder path, the source kind and the version; "Changes" lists every generated file.
+
+## Step 3: read the files in order and present them
+1. integrate.prd.md - the requirement restated in this project's own business terms, business units and code locations.
+2. prd.plan.md - the implementation plan. If it is an overview (it has a sub-plans section), read prd.plan.01-*.md, 02-*.md ... in order; each sub-plan states its dependencies.
+3. original.prd.md - the source; consult it only when the first two are ambiguous.
+Present to the user: the key points of the restatement, the business units and code involved, how many plans and what each covers, the open questions, and this version number.
+
+After every generation or revision (`--no-plan` and `--plan-only` included), first give the user a **summary of this version** with four fixed items:
+1. **Version**: vn; for a revision, vold → vnew.
+2. **What changed**: for a new document, the gist of the restatement and of the plans; for a revision, go through the "restatement sections changed" listed under "Result" section by section and say what each now reads (open the file and read them, never from memory), and through the plan files the "Changes" section lists as added / updated / removed.
+3. **Questions for the developer**: every item under "New questions" (subject, severity, question file), plus the rest of the "Open questions" section of integrate.prd.md; "none" when there are none.
+4. **Can it be implemented directly**: relay the development-threshold line under "Next", and what is missing when it is not ready.
+
+## Step 4: ask for review
+Ask three things: is the restatement right, can the plan be done this way, how should the open questions be answered. Then:
+- Changes wanted: let the user edit the files, or rerun this command with the document id and the feedback (`/auto-feat <document id> <feedback>`); the engine produces a new version; back to step 3.
+- Confirmed: set `confirmation` to `confirmed` in the frontmatter of integrate.prd.md and every plan file. That is the only field you may change.
+- Undecided: change nothing; the documents stay pending.
+
+## Step 5: may the knowledge base carry the implementation
+Read the development-threshold line under "Next" in step 2's output (`data.dev` with `--json`).
+- Ready (`dev.ready` is true) and the user confirmed the restatement and every plan in step 4 → ask the user whether to implement the plan now. Start only on a yes:
+  - Implement strictly along the plan steps and the code locations and anchors the restatement lists; before touching code, read the related knowledge-base documents with `autocode query <anchor> --json`, then the code.
+  - After each plan step, tell the user which files it changed.
+  - When a module, interface or data structure outside the plan has to change, stop and ask the user first.
+  - At the end, list every changed file with its plan step and ask the user to review the code.
+- Not ready (`dev.ready` is false), documents unconfirmed, or the user does not want it now → relay what the "First" list names (answer questions, confirm business terms, run /auto-wiki first); this command ends here. Do not start writing code; do not run autocode wiki.
+
+On either branch, never run autocode wiki and never change files under `.autocode/`; the knowledge base updates when the user runs /auto-wiki, from the code and the confirmed documents.
+
+## Never
+- Outside the ready branch of step 5, never implement the requirement or change business code; never implement below the threshold or on unconfirmed documents.
+- Never create or edit anything under `.autocode/`; the only exception is the `confirmation` field after the user explicitly confirms.
+- Never answer the engine's questions on the user's behalf.
+- Never put the source into the command-line argument; never rewrite or summarise it.
+- Pending documents are not read by the knowledge base; never imply they already are.

package/dist/hosts/templates/en/commands/auto-fix.ejs

@@ -0,0 +1,69 @@
+---
+description: Locate the original defect report (pasted error / ticket URL / work item / file), produce the defect analysis restated in this project's business terms plus a fix plan, for review and confirmation; fixes along the plan once the knowledge base reaches the development threshold and the user agrees
+argument-hint: "<what to fix, or where the report is: pasted text / URL / work item / file>"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep, Edit, WebFetch, mcp__*
+<% } -%>
+autocode-template: 3
+---
+
+# /auto-fix
+
+## Step 1: locate the original defect report
+`$ARGUMENTS` is what the user said, not necessarily the report itself. Decide where the source is, in this order, and stop at the first hit:
+1. The user pasted an error, log or reproduction steps → that is the source; take it verbatim, never rewrite or summarise.
+2. The user gave a ticket URL → fetch the page body with the web-fetch tool.
+3. The user refers to a work item in a project tool (Feishu Project, Jira, ...) → fetch title, description and reproduction steps with the matching MCP tool.
+4. The user refers to a file in the repo → Read it.
+5. None of the above → the user's words are the source; append the relevant symptoms, expected behaviour and known files from the conversation, each marked "from conversation".
+Put one source comment on the first line of the text: `<!-- autocode-source: conversation|url|mcp|file|prompt <reference> -->`.
+When fetching the source:
+- Feishu / Lark document links (`/wiki/`, `/docx/`) cannot be web-fetched: use lark-cli or a Feishu MCP when available to get the Markdown body, and download the images in it.
+- Pages behind a login or rendered by scripts: use a browser automation tool when available.
+- PDF: Read it directly (images and CJK PDFs included); do not use extraction tools such as pdftotext.
+- Images, interface documents and other material the source refers to are not pasted into it: put them in a scratch folder inside the repo (not under `.autocode/`) and hand it over with `--attachments` in step 2. The engine keeps a copy in the change folder; the scratch folder can go afterwards.
+
+## Step 2: run (source goes through stdin)
+    autocode fix "$ARGUMENTS" <<'AUTOCODE_ORIGINAL'
+    <source text>
+    AUTOCODE_ORIGINAL
+Bash tool, timeout of at least <%= timeoutMinutes %> minutes. The source always goes through stdin, never into the argument.
+- Material to hand over: add `--attachments <scratch folder>`.
+- The user says "no plan yet" / "just the restatement": add `--no-plan` and read only the integrate document in step 3; when the user wants the plan later, run `autocode fix --plan-only <document id>` (plans from the existing restatement, reads no stdin).
+The "Result" section gives the folder path, the source kind and the version; "Changes" lists every generated file.
+
+## Step 3: read the files in order and present them
+1. integrate.defect.md - the symptom, root cause and related business rules restated in this project's own business terms.
+2. defect.plan.md - the fix plan. If it is an overview (it has a sub-plans section), read defect.plan.01-*.md, 02-*.md ... in order.
+3. original.defect.md - the source; consult it only when the first two are ambiguous.
+Present to the user: the restated symptom, the root cause (or the candidate list when it says "not located"), how many plans and what each covers, the open questions, and this version number. When the root cause is "not located", give the user the candidates and rerun with the id once they add clues.
+
+After every generation or revision (`--no-plan` and `--plan-only` included), first give the user a **summary of this version** with four fixed items:
+1. **Version**: vn; for a revision, vold → vnew.
+2. **What changed**: for a new document, the gist of the symptom and root cause and of the plans; for a revision, go through the "restatement sections changed" listed under "Result" section by section and say what each now reads (open the file and read them, never from memory), and through the plan files the "Changes" section lists as added / updated / removed.
+3. **Questions for the developer**: every item under "New questions" (subject, severity, question file), plus the rest of the "Open questions" section of integrate.defect.md; "none" when there are none.
+4. **Can it be fixed directly**: relay the development-threshold line under "Next", and what is missing when it is not ready.
+
+## Step 4: ask for review
+Ask three things: are the symptom and root cause right, can the plan be done this way, how should the open questions be answered. Then:
+- Changes wanted: let the user edit the files, or rerun this command with the document id and the feedback (`/auto-fix <document id> <feedback>`); the engine produces a new version; back to step 3.
+- Confirmed: set `confirmation` to `confirmed` in the frontmatter of integrate.defect.md and every plan file. That is the only field you may change.
+- Undecided: change nothing; the documents stay pending.
+
+## Step 5: may the knowledge base carry the fix
+Read the development-threshold line under "Next" in step 2's output (`data.dev` with `--json`).
+- Ready (`dev.ready` is true) and the user confirmed the restatement and every plan in step 4 → ask the user whether to fix the plan now. Start only on a yes:
+  - Fix strictly along the plan steps and the code locations and anchors the restatement lists; before touching code, read the related knowledge-base documents with `autocode query <anchor> --json`, then the code.
+  - After each plan step, tell the user which files it changed.
+  - When a module, interface or data structure outside the plan has to change, stop and ask the user first.
+  - At the end, list every changed file with its plan step and ask the user to review the code.
+- Not ready (`dev.ready` is false), documents unconfirmed, or the user does not want it now → relay what the "First" list names (answer questions, confirm business terms, run /auto-wiki first); this command ends here. Do not start writing code; do not run autocode wiki.
+
+On either branch, never run autocode wiki and never change files under `.autocode/`; the knowledge base updates when the user runs /auto-wiki, from the code and the confirmed documents.
+
+## Never
+- Outside the ready branch of step 5, never fix the defect or change business code; never fix below the threshold or on unconfirmed documents.
+- Never create or edit anything under `.autocode/`; the only exception is the `confirmation` field after the user explicitly confirms.
+- Never answer the engine's questions on the user's behalf.
+- Never put the source into the command-line argument; never rewrite or summarise it.
+- Pending documents are not read by the knowledge base; never imply they already are.

package/dist/hosts/templates/en/commands/auto-init.ejs

@@ -0,0 +1,22 @@
+---
+description: Initialise or refresh autocode - skeleton, code graph, host integration (zero AI)
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep
+<% } -%>
+autocode-template: 1
+---
+
+# /auto-init
+
+## Run
+From the project root, with the Bash tool and a timeout of at least <%= timeoutMinutes %> minutes; never use inline `!` execution:
+    autocode init
+
+## Relay
+The output is sectioned Markdown. Relay it section by section, verbatim in substance; do not embellish or add conclusions the engine did not state.
+- An empty "Changes" section means the repo was already initialised and this was a refresh; say so.
+- "no usable provider" means Claude Code or the Codex CLI is missing; it does not affect initialisation itself.
+
+## Never
+- Never create or edit anything under `.autocode/`; it is generated.
+- Never decompose the work yourself or bypass the command to edit documents; the workflow lives in the engine.

package/dist/hosts/templates/en/commands/auto-wiki.ejs

@@ -0,0 +1,42 @@
+---
+description: Generate or update the business knowledge base; accepts a natural-language instruction
+argument-hint: "[instruction, e.g. only one module / preview / rewrite everything]"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep, Edit
+<% } -%>
+autocode-template: 2
+---
+
+# /auto-wiki
+
+## Run
+From the project root, with the Bash tool and a timeout of at least <%= timeoutMinutes %> minutes; never use inline `!` execution:
+    autocode wiki "$ARGUMENTS"
+(Pass no quotes when there is no argument.)
+If the user states how the business actually works (business facts), pass them in the instruction as they are: the engine records their words as human-confirmed answers and edits the related documents accordingly; do not look for a file to write them into.
+If the instruction means rewriting every document ("rewrite everything", "full"), it is expensive and irreversible: confirm with the user first.
+
+## Relay
+The output is sectioned Markdown. Relay it section by section; do not embellish or add conclusions the engine did not state.
+- A "preview" instruction only prints the affected list; relay it as is.
+- "Nothing to update" is a valid outcome; relay the reason.
+- "cannot resolve the instruction" → relay the reason, then use `autocode query <keyword>` to find the related unit documents and domains (the document file names and domain ids it reports) and list them for the user to confirm; once they agree, run `autocode wiki --scope unit:<file>,domain:<domain id>` (no instruction) to rewrite only those.
+- "No document relates to the request" → handle it like the previous item: find the related documents with `autocode query`, and run with `--scope` once the user confirms.
+- "Review unmet" under next steps → relay each one (the requirement as quoted + what is missing) and ask whether to rephrase and run again, or leave it.
+- "not initialised" → suggest /auto-init; "no usable provider" → suggest installing Claude Code or the Codex CLI.
+
+## Questions
+The engine never stops to ask: where it was unsure it wrote the documents on an assumption and left the question in the output. Now you ask.
+<% if (host === "claude") { -%>
+1. For every item under "Answer first", ask the user with the question tool (AskUserQuestion): title = the subject, description = the current-behaviour line from the output, options = the options from the output plus "Other" and "Later". Never invent options; never choose for the user.
+<% } else { -%>
+1. For every item under "Answer first", list the subject, current behaviour and options in the conversation and ask the user to answer. Never invent options; never choose for the user.
+<% } -%>
+2. When the user answers (an answer of "accept" is written as is: the engine then adopts the document's assumption), open that question file and write the answer verbatim under `## 回答 / Answer` (no summary, no additions); set three frontmatter fields: `status: answered`, `answered_at: <ISO time now>`, `answered_via: host-agent`. Touch nothing else. Leave "Later" items untouched.
+3. If at least one answer was written, run `autocode wiki` once more without an instruction (incremental) and relay the result; the affected documents are updated from the answers in that pass.
+4. "New questions" are listed only; say they can be answered now, or later by writing directly under `## 回答 / Answer` in the question file (`.autocode/questions/`), which takes effect on the next `autocode wiki`. Handle any the user wants to answer now with step 2.
+
+## Never
+- Never create or edit anything under `.autocode/`; the only exception is writing the user's answer in Questions step 2.
+- Never answer the engine's questions on the user's behalf; never rephrase the user's answer.
+- Never decompose the work yourself or bypass the command to edit documents; the workflow lives in the engine.

package/dist/hosts/templates/en/marker-block.ejs

@@ -0,0 +1,6 @@
+## autocode business knowledge base (maintained by autocode install; do not edit this block)
+This repository keeps a business knowledge base in `.autocode/`: code says "how", the knowledge base says "why and under which rules". Query before coding: `autocode query <keyword or anchor> --json` (documents, business terms, entries, anchors; a document's frontmatter `up` / `down` point to the next layer), `autocode graph <anchor> --json` (call relations), question files with `status: open` under `.autocode/questions/` (open questions).
+Business-term discipline: reuse the names from the business terms verbatim; never coin synonyms; a term whose status is confirmed is the settled wording.
+Only two things may be written into `.autocode/`: the user's answer to a question (verbatim, into the question file's answer section) and the user's confirmation of a requirement / defect document (the `confirmation` field); nothing else.
+Do not go back and change requirement / defect documents when changing code; they record the intent at the time. The knowledge base follows the code; divergences become questions at the next wiki update for a human to settle.
+Slash commands and their CLI (Codex users call the CLI on the right directly): /auto-init → `autocode init`; /auto-wiki → `autocode wiki "<instruction>"`; /auto-check → `autocode check`; /auto-feat → `autocode feat "<the user's words>" < source`; /auto-fix → `autocode fix "<the user's words>" < source`.

package/dist/hosts/templates/en/skill-graph.ejs

@@ -0,0 +1,30 @@
+---
+name: autocode-graph
+description: Query this repository's code-graph call chains - give an anchor (a function, method or type name; a shared name written file::qualifiedName) or a keyword and get the multi-hop chain of who calls it and what it calls (the graph engine's own call graph), plus the symbols in its file; list every entry (routes, pages, jobs, consumers). Query before walking a call chain or locating code instead of grepping file by file. For the business meaning use autocode-query; for the tools see autocode.
+autocode-template: 2
+---
+
+# autocode code graph
+
+autocode builds the code graph from the source; it is the bottom layer of the knowledge base, and the anchors in documents are its node names. `autocode graph` calls the graph engine's own call graph and search directly: read-only, no AI, usable while a wiki runs.
+
+## Query
+| Need | Command |
+|---|---|
+| an anchor's call chain (2 hops each way by default) | `autocode graph <anchor>` (call trees to read) / `autocode graph <anchor> --json` (machine-readable) |
+| look further or closer | `--depth <1-5>` |
+| only part of the name is known | `autocode graph <keyword>` (the graph engine's full-text / fuzzy search) |
+| which entries exist and which unit document covers each | `.autocode/entries.md` (entry catalog by module, with node names, files and lines) |
+
+## Reading the result
+- Without `--json`: the first line is the resolved symbol with its file and line, then two trees — "callers" (`←`, what reaches it) and "callees" (`→`, where it goes); one indent is one hop more; `(↺)` marks a node already shown (recursion or a join), `… +N` a level cut for width.
+- `--json`: `symbol`; `chain.nodes` (each node's `anchor`, `kind`, file and line), `chain.edges` (`from` → `to`, with the call-site line), `chain.tree` (the same two trees as text); `callers` / `callees` are the one-hop short lists, `siblings` the symbols of the same file.
+- "N symbols share that name" / `candidates.reason = ambiguous`: nothing is guessed; pick one and query again with its `file::qualifiedName`.
+- "no symbol has that name; the search found" / `candidates.reason = keyword`: pick a hit and query again; a single hit is already explored. `truncated` true means there are more; use a more specific keyword.
+- "nothing in the graph": it may be a variable or a constant (use Grep), or refresh the graph by running /auto-wiki first.
+
+## With the knowledge base
+- From business words: find the documents with `autocode query` first; the `anchors` and `entries` in their frontmatter are names to query the graph with.
+- From code: with an anchor in hand, `autocode query <anchor> --json` tells which unit document and domain it belongs to.
+
+This file is maintained by `autocode install`; manual edits are overwritten on the next install.

package/dist/hosts/templates/en/skill-query.ejs

@@ -0,0 +1,34 @@
+---
+name: autocode-query
+description: Query the documents of this repository's business knowledge base (.autocode/) - find documents by anchor or by business words, read what a piece of code means for the business, its rules, which business a change affects, the exact wording of a business term. Query before coding instead of guessing from source. For call relations and code structure use autocode-graph; for updating documents and the other tools see autocode.
+autocode-template: 2
+---
+
+# autocode knowledge-base query
+
+Code answers "how"; the knowledge base answers "why, for whom, under which rules".
+
+## Query (before coding)
+| Need | Command |
+|---|---|
+| an anchor (function, method or type name) or business words → related documents, business-term definitions, entries, related requirement documents | `autocode query <anchor or keyword> --json` |
+| call relations, what a name is in the code | see the autocode-graph skill |
+| open business questions | question files with `status: open` under `.autocode/questions/` |
+
+## Layers and how to read them
+The knowledge base has four layers, bottom to top; each document's frontmatter `layer` says which, and `up` / `down` point one layer up and down (paths relative to `.autocode/`):
+1. code graph: query it with `autocode graph` (autocode-graph skill)
+2. entries: `.autocode/entries.md`, one line per entry with its node name, file and line, and the unit document covering it
+3. units: one document per business capability; `down` points at its entries
+4. domains: one document per module, the end-to-end journey; `down` lists its units
+
+- Holding an anchor (a function, method or type name) or an entry (a route, a page path): `autocode query <anchor> --json`; documents naming that anchor come first (`anchorHit`) and `entries` gives its place in the entry catalog; follow `up` to the domain and `down` to the entries; read the implementation with `autocode graph <anchor>`.
+- Holding business words: query the business term first, read the documents it hits, and walk `up` / `down` the same way.
+- A document's `confidence` is computed by code (the generation's own assessment, open questions, stale anchors, pending business terms); its closing "Development entry" section says whether it is ready for automated development and what is missing.
+
+Every turn already injects where the knowledge base lives, the domain catalog, and the business terms and document clues picked from the current message and the recent turns (with why each was picked); the clues are not complete — never guess content from a title, read the document or fetch it with query.
+
+## Business-term discipline
+In identifiers, comments, documents and PR descriptions, reuse the names from the business terms verbatim, a confirmed term being the settled wording; query when unsure; ask the user in the conversation when nothing is found.
+
+This file is maintained by `autocode install`; manual edits are overwritten on the next install.

package/dist/hosts/templates/en/skill.ejs

@@ -0,0 +1,54 @@
+---
+name: autocode
+description: How to use the tools that maintain this repository's business knowledge base (.autocode/) - onboarding (init), generating and updating documents (wiki), the health check (check), restating requirements (feat) and defects (fix), host installation (install / uninstall), their extra flags, and what people maintain by hand. Read it to update documents, write requirement or defect documents, or look into a knowledge-base problem; to read documents use autocode-query, for code structure autocode-graph.
+autocode-template: 4
+---
+
+# autocode knowledge-base tools
+
+The engine generates and maintains the knowledge base `.autocode/`: you run the commands and relay their results faithfully; you never edit documents by hand. The slash commands are these commands' entry points in the host (Codex calls the CLI on the right directly). The Claude Code / Codex the engine starts sees what a developer starting it in this directory sees — the skills, plugins, slash commands and MCP servers here — under the developer's own permission settings.
+
+## Commands
+| Command | Slash command | What it does | AI |
+|---|---|---|---|
+| `autocode init` | /auto-init | onboard a repository: skeleton, code graph, reference index, available models | no |
+| `autocode wiki ["instruction"]` | /auto-wiki | generate / update the knowledge-base documents | yes |
+| `autocode check` | /auto-check | health check: stale anchors, coverage blind spots, pending business terms, documents below the development threshold… | no |
+| `autocode feat "<user's words>" < original` | /auto-feat | restate a requirement in this project's business terms and plan it | yes |
+| `autocode fix "<user's words>" < original` | /auto-fix | restate a defect, locate its cause and plan the fix | yes |
+| `autocode install [claude\|codex\|all]` | — | install / refresh the host files (slash commands, skills, marker blocks, hooks) | no |
+| `autocode uninstall [claude\|codex\|all]` | — | remove the host files; the knowledge base stays | no |
+
+Every command takes `--json` for the machine-readable envelope; the default output is sectioned Markdown (result / changes / questions / next), relayed section by section.
+
+## wiki
+- Without an instruction: incremental. Code changes, answered questions, changed business terms and entries without a document decide which documents change, one call per document; when nothing changed it calls no AI and only refreshes the layer links, the confidence and the development-entry section.
+- With an instruction (natural language): "update only module X", "add to the entry Y", "preview", "rewrite everything". Unit titles, entries, anchors and domain names the instruction names are matched by code; business facts it states are recorded as human-confirmed answers. "Rewrite everything" is expensive: ask the user first.
+- `--scope unit:<file name>,domain:<domain id>`: rewrite exactly these documents (no instruction).
+- `--check`: run check first and rewrite only the documents its report names (same as `autocode check --fix`).
+- Only one wiki / init / `check --fix` runs at a time (they rewrite the knowledge base); query, graph, check, feat and fix may run alongside. On "another … is running", wait for it to end and retry; do not rebuild the code graph.
+- Handle the questions in the output as the /auto-wiki "Questions" section says; after writing answers back, run wiki once more without an instruction.
+
+## check
+- Zero AI; findings grouped by severity. `--fix`: after the report, rewrite the documents with stale anchors or broken rules.
+- Usual findings: `stale-anchor` · `anchor-loose` (an older anchor that breaks the rule; fixed at the next rewrite) · `term-pending` (business terms awaiting a human) · `dev-below-threshold` (below the development threshold, with what holds it back) · `layer-link-dangling` (fixed by the next wiki) · `host-outdated` (run `autocode install`).
+
+## feat / fix
+- The original always goes through stdin (heredoc); the argument carries only the user's words. Rerunning with the document id revises it into a new version.
+- `--no-plan`: write the original and the restatement only; once settled, `--plan-only <document id>` plans from the restatement.
+- `--attachments <folder inside the repo>`: images, PDFs, interface documents; the engine keeps a copy in the change folder.
+- `dev` in the result: whether every document involved reaches the development threshold, with what holds it back otherwise; only when ready and confirmed by the user may the plan be implemented (step 5 of /auto-feat and /auto-fix).
+
+## What people maintain by hand (extended use)
+- Answers: the `## Answer` section of a question file under `.autocode/questions/`, taken up by the next wiki.
+- Confirming business terms: set the leading "Status" column of a business-term row to confirmed; the AI never changes it again, the documents using it are updated and their confidence rises.
+- Project brief `.autocode/project.md`: facts and the module split written by the project owner; it outranks anything inferred from code.
+- Configuration `.autocode/config.yaml`: `wiki.devThreshold` (development threshold, 0.8 by default), `wiki.reviewRounds`, `budget`, `concurrency`, `entries.exclude`.
+- Requirement / defect documents: people may edit the restatement and the plans; set `confirmation` to `confirmed` when settled; unconfirmed ones are not read by the knowledge base.
+
+## The only two things you may write
+- The user's answer to a question: verbatim, into the question file's answer section.
+- The user's confirmation of a requirement / defect document: the `confirmation` field.
+Nothing else. After code changes the user runs /auto-wiki to update the knowledge base. Do not go back and change requirement / defect documents when changing code: they record the intent at the time and divergence from the code is normal; the knowledge base follows the code, and divergences become questions at the next wiki update for a human to settle.
+
+This file is maintained by `autocode install`; manual edits are overwritten on the next install.

package/dist/hosts/templates/zh/commands/auto-check.ejs

@@ -0,0 +1,25 @@
+---
+description: 知识库体检:失效、孤儿、frontmatter、宿主文件版本、技术债(零 AI)
+argument-hint: "[范围]"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep
+<% } -%>
+autocode-template: 1
+---
+
+# /auto-check
+
+## 调用
+在项目根目录用 Bash 工具执行,超时不少于 <%= timeoutMinutes %> 分钟,不要用内联 `!` 执行:
+    autocode check "$ARGUMENTS"
+(无参数时不传引号对。)
+
+## 转述
+命令输出是分节 Markdown,按「高 / 中 / 低」如实转述给用户;不美化、不补写引擎没说的结论。
+- `host-outdated` 表示宿主侧文件缺失或版本落后,建议用户运行 `autocode install`。
+- 报错「未初始化」→ 提示先运行 /auto-init。
+
+## 禁止
+- 不要创建或编辑 `.autocode/` 下的任何文件,那是生成物。
+- 不要替用户回答引擎提出的问题。
+- 不要自行拆解步骤或绕过命令直接改文档;工作流全部在引擎内。

package/dist/hosts/templates/zh/commands/auto-feat.ejs

@@ -0,0 +1,69 @@
+---
+description: 找到原始需求文档(对话粘贴 / URL / 工作项 / 文件),生成用本项目业务术语整合重述的需求与实现计划,供审阅与确认;知识库达到开发阈值且用户同意时按计划实现
+argument-hint: "<要做什么,或原文在哪:粘贴的内容 / URL / 工作项 / 文件>"
+<% if (host === "claude") { -%>
+allowed-tools: Bash(autocode:*), Read, Glob, Grep, Edit, WebFetch, mcp__*
+<% } -%>
+autocode-template: 3
+---
+
+# /auto-feat
+
+## 第一步:找到原始需求文档
+`$ARGUMENTS` 是用户的话,不一定是需求本身。按下面顺序判断原文在哪,取到即止:
+1. 用户在对话里粘贴了需求原文 → 原文就是它,逐字取用,不改写、不概括。
+2. 用户给了 URL → 用网页抓取工具取回正文。
+3. 用户指的是项目管理工具里的工作项(飞书项目、Jira 等)→ 用对应 MCP 工具取回标题、描述、验收标准。
+4. 用户指的是仓库里的文件 → Read。
+5. 都不是 → 用户的话本身就是原文;再把对话里相关的背景、目标、已知文件、约束逐条补在后面,标明「来自对话」。
+取回的原文第一行写一条来源注释:`<!-- autocode-source: conversation|url|mcp|file|prompt <引用> -->`。
+取原文时还要注意:
+- 飞书 / Lark 文档链接(`/wiki/`、`/docx/`)用网页抓取拿不到:有 lark-cli 或飞书 MCP 就用它取 Markdown 正文,正文里的图片一并下载。
+- 要登录或靠脚本渲染的网页:有浏览器自动化工具就用它取正文。
+- PDF:直接用 Read 读(图片和中文 PDF 都能读),不要用 pdftotext 一类的抽取工具。
+- 原文引用的图片、接口文档等材料不要拼进原文:放进仓库里的一个临时文件夹(不放在 `.autocode/` 下),第二步用 `--attachments` 交给引擎。引擎会复制一份到变更文件夹,之后临时文件夹可以删掉。
+
+## 第二步:调用(原文走 stdin)
+    autocode feat "$ARGUMENTS" <<'AUTOCODE_ORIGINAL'
+    <原文>
+    AUTOCODE_ORIGINAL
+Bash 工具,超时不少于 <%= timeoutMinutes %> 分钟。原文一律用 stdin,不塞进参数。
+- 有附件:加 `--attachments <临时文件夹>`。
+- 用户说「先不出计划」「只要重述」这类意思:加 `--no-plan`,第三步只读整合文档;之后用户要计划时运行 `autocode feat --plan-only <文档id>`(按已有重述只生成计划,不读 stdin)。
+输出的「结果」给出文件夹路径、原文来源与版本号,「变更」列出生成的每份文件。
+
+## 第三步:按顺序读文件,呈现给用户
+1. integrate.prd.md —— 用这个项目自己的业务术语、业务单元和代码位置整合重述的需求。
+2. prd.plan.md —— 实现计划。若它是总览(有「子计划」一节),再按编号依次读 prd.plan.01-*.md、02-*.md……;每份子计划标了依赖。
+3. original.prd.md —— 原文,只在前两份有歧义时回看。
+向用户呈现:需求重述的要点、涉及的业务单元与代码、计划份数与每份范围、未决问题、本次版本号。
+
+每次生成或改版之后(包括 `--no-plan`、`--plan-only`),先给用户一段**本次版本小结**,固定四项:
+1. **版本**:v版本号;改版时写 v旧 → v新。
+2. **本次修改**:新建时概括需求重述与计划要点;改版时按输出「结果」里的「整合文档改动段落」逐段读这些段落的新内容,说明这一版改成了什么(打开文件读,不凭印象),计划按「变更」里新增 / 更新 / 移除的文件逐份说明。
+3. **需要开发回答的问题**:输出「新增问题」逐条列出(主题、级别、问题文件路径),加上integrate.prd.md「未决问题」一节里的其余问题;没有就写「无」。
+4. **能否直接实现**:转述「后续」里关于开发阈值的那一行,未达标时说明还差什么。
+
+## 第四步:请用户审阅
+问用户三件事:需求重述对不对、计划能不能这样做、未决问题怎么答。按回答处理:
+- 要改:让用户直接编辑文件,或把修改意见带上文档 id 重跑本命令(`/auto-feat <文档id> <修改意见>`),引擎会生成新版本,再回到第三步。
+- 确认:把 integrate.prd.md 与每份计划文件 frontmatter 的 `confirmation` 改为 `confirmed`。这是你唯一可以改动的字段。
+- 还没想好:什么都不改,文档保持 pending。
+
+## 第五步:能否据知识库直接实现
+看第二步输出「后续」里关于开发阈值的那一行(`--json` 时是 `data.dev`)。
+- 达标(`dev.ready` 为真),且用户在第四步确认了整合文档与全部计划 → 问用户「要现在按计划实现吗」。用户同意才开始:
+  - 严格按计划步骤和整合文档列出的代码位置、锚点实现;动手前先用 `autocode query <锚点> --json` 读相关知识库文档,再读代码。
+  - 每完成一个计划步骤,告诉用户这一步改了哪些文件。
+  - 需要动计划之外的模块、接口或数据结构时,先停下来问用户。
+  - 结束时列出全部改动文件和对应的计划步骤,请用户审代码。
+- 未达标(`dev.ready` 为假)、文档未确认、或用户不想现在实现 → 把「先处理」列出的内容转述给用户(回答问题、确认业务术语、先运行 /auto-wiki),本命令到此结束。不要开始写代码,不要运行 autocode wiki。
+
+无论哪个分支,都不要运行 autocode wiki、不要改 `.autocode/` 下的文件;知识库会在用户运行 /auto-wiki 时,根据代码与已确认文档的变化更新。
+
+## 禁止
+- 除第五步的达标分支外,不要实现需求、改业务代码;未达标或文档未确认时一律不实现。
+- 不要创建或编辑 `.autocode/` 下的任何内容;唯一例外是用户明确确认后改 `confirmation` 字段。
+- 不要替用户回答引擎提出的问题。
+- 不要把原文塞进命令行参数;不要改写或概括原文。
+- 未确认(pending)的文档不会被知识库读取,不要向用户暗示「已经进知识库」。