facult 2.15.2 → 2.16.0

package/README.md

@@ -262,6 +262,7 @@ fclt ai writeback summarize --by kind
 Draft a proposal only when the evidence repeats, a capability is clearly missing, or a canonical asset is stale:
 
 ```bash
+fclt ai evolve assess --asset instruction:VERIFICATION --json
 fclt ai evolve propose
 fclt ai evolve list
 fclt ai evolve draft EV-00001
@@ -389,7 +390,7 @@ Writeback and evolution:
 ```bash
 fclt ai writeback add --kind <kind> --summary <text> --asset <selector>
 fclt ai writeback list|show|group|summarize
-fclt ai evolve propose|list|show|draft|review|accept|reject|apply|promote
+fclt ai evolve assess|propose|list|show|draft|review|accept|reject|apply|promote
 ```
 
 Sources, audit, and updates:

package/assets/packs/facult-operating-model/instructions/EVOLUTION.md

@@ -78,6 +78,7 @@ Typical workflow:
 fclt ai writeback add --kind weak_verification --summary "Checks were too shallow" --asset instruction:VERIFICATION
 fclt ai writeback group --by asset
 fclt ai writeback summarize --by domain
+fclt ai evolve assess --asset instruction:VERIFICATION --json
 fclt ai evolve propose
 fclt ai evolve draft EV-00001
 fclt ai evolve accept EV-00001
@@ -91,6 +92,7 @@ Review surfaces:
 - open `~/.ai/writebacks/` and `~/.ai/evolution/` in a Markdown editor for frontmatter-rich global and project-scoped review artifacts
 - `fclt status --json` for queue/proposal paths, review artifact paths, counts, and active scope
 - `fclt ai writeback list|show|group|summarize` for raw and clustered signal
+- `fclt ai evolve assess` for read-only proposal readiness and the safest next action
 - `fclt ai evolve list|show|review` for proposal state without applying changes
 - `fclt templates init automation learning-review` for recurring capture/review
 - `fclt templates init automation evolution-review` for recurring proposal review
@@ -110,8 +112,11 @@ Use the smallest action that fits the signal:
 
 1. record one strong writeback when there is a clear durable learning
 2. use `writeback-curator` when the target, kind, or scope is ambiguous
-3. use `capability-evolution` or `evolution-planner` when repeated signal should become a proposal
-4. do not draft or apply proposals just because a writeback exists; require repeated evidence or a clearly missing capability
+3. run `fclt ai evolve assess --asset <selector> --json` before proposing when a target is known
+4. use `capability-evolution` or `evolution-planner` when repeated signal should become a proposal
+5. do not draft or apply proposals just because a writeback exists; require repeated evidence or a clearly missing capability
+
+When assessment recommends no mutation or more writeback, agents should still produce a useful review: state the current target, evidence grade, missing signal, exact recurrence that would justify evolution, and any read-only follow-up. Do not end with only "no proposal".
 
 Avoid creating writeback/evolution noise for one-off nits, vague preferences, or speculative ideas without evidence.
 

package/assets/packs/facult-operating-model/skills/capability-evolution/SKILL.md

@@ -28,11 +28,12 @@ Reject global scope when the proposal depends on private examples, one repo's ar
 
 1. Read current writebacks and existing proposals.
 2. Group or summarize repeated signal by asset, kind, and scope.
-3. Check the current target asset before proposing a change.
-4. Choose the smallest valid proposal kind.
-5. Draft the proposal with evidence and intended target.
-6. Accept only after the target and scope are correct.
-7. Apply only when the markdown target is the intended canonical asset.
+3. Run a read-only evolution assessment for the target when possible.
+4. Check the current target asset before proposing a change.
+5. Choose the smallest valid proposal kind.
+6. Draft the proposal with evidence and intended target.
+7. Accept only after the target and scope are correct.
+8. Apply only when the markdown target is the intended canonical asset.
 
 Use:
 
@@ -40,6 +41,7 @@ Use:
 fclt ai writeback add ...
 fclt ai writeback group --by asset
 fclt ai writeback summarize --by domain
+fclt ai evolve assess --asset <selector> --json
 fclt ai evolve propose
 fclt ai evolve draft EV-00001
 fclt ai evolve draft EV-00001 --append "tighten the rule with a concrete verification step"
@@ -55,7 +57,7 @@ fclt templates init automation evolution-review
 fclt templates init automation tool-call-audit
 ```
 
-If there is not yet enough repeated signal for evolution, record the writeback and stop there.
+If there is not yet enough repeated signal for evolution, do not stop at a bare "no". Explain what evidence would change the decision, whether another writeback should be recorded, and the smallest future target if the pattern repeats.
 
 Do not create a proposal only to preserve an idea. Preserve the idea as writeback, notes, or task tracking unless it has enough evidence to change capability.
 
@@ -87,3 +89,5 @@ Before accept/apply, verify:
 - evidence
 - smallest useful next step
 - approval or no-op rationale
+- next evidence to collect when no proposal is justified
+- exact read-only and mutating commands, with approval boundaries

package/docs/codex-plugin.md

@@ -54,4 +54,6 @@ bun run check
 
 Use the plugin skills as the first interface. Use MCP tools when a Codex workflow benefits from structured calls for status, doctor, paths, writeback, or evolution review.
 
-Do not create writeback/evolution noise. Record strong signal, group repeated signal, then propose the smallest concrete capability change.
+For proposal triage, call `fclt_evolve` with `action: "assess"` before proposing when a target is known. Assessment is read-only and returns the recommendation, source writebacks, active proposal ids, quality checklist, suggested commands, and the next agent instruction.
+
+Do not create writeback/evolution noise. Record strong signal, group repeated signal, assess readiness, then propose the smallest concrete capability change only when evidence repeats or the missing capability is clear.

package/docs/reference.md

@@ -84,6 +84,7 @@ fclt ai writeback show WB-00001
 fclt ai writeback group --by asset
 fclt ai writeback summarize --by kind
 
+fclt ai evolve assess --asset <selector> --json
 fclt ai evolve propose
 fclt ai evolve list
 fclt ai evolve show EV-00001

package/docs/writeback-evolution.md

@@ -42,10 +42,15 @@ Review accumulated signal:
 fclt ai writeback list
 fclt ai writeback group --by asset
 fclt ai writeback summarize --by kind
+fclt ai evolve assess --asset instruction:VERIFICATION --json
 fclt ai evolve propose
 fclt ai evolve list
 ```
 
+Use `assess` as the read-only gate for agent-led review UI. It returns a recommendation (`no_mutation`, `record_more_writeback`, `propose`, or `review_existing_proposal`), source writeback ids, active proposal ids, a quality checklist, suggested commands, and the next agent instruction.
+
+For a single weak or medium-confidence writeback, the right answer is usually more evidence, not a proposal. A useful no-op still explains what recurrence would change the decision and where the next writeback should land.
+
 Draft and review:
 
 ```bash

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "facult",
-  "version": "2.15.2",
+  "version": "2.16.0",
   "description": "Manage canonical AI capabilities, sync surfaces, and evolution state.",
   "type": "module",
   "license": "MIT",

package/plugins/fclt/scripts/fclt-mcp.cjs

@@ -92,7 +92,8 @@ const tools = [
   },
   {
     name: "fclt_evolve",
-    description: "List, propose, draft, or review fclt evolution proposals.",
+    description:
+      "Assess, list, propose, draft, or review fclt evolution proposals.",
     inputSchema: {
       type: "object",
       properties: {
@@ -100,9 +101,10 @@ const tools = [
         cwd: { type: "string" },
         action: {
           type: "string",
-          enum: ["list", "propose", "draft", "review", "show"],
+          enum: ["assess", "list", "propose", "draft", "review", "show"],
         },
         id: { type: "string" },
+        asset: { type: "string" },
       },
     },
   },
@@ -176,7 +178,11 @@ function commandForTool(name, args = {}) {
         "evolve",
         ...scopeArgs(args.scope),
         action,
+        ...(action === "assess" || action === "propose"
+          ? stringFlag("--asset", args.asset)
+          : []),
         ...(args.id ? [args.id] : []),
+        ...(action === "assess" ? ["--json"] : []),
       ];
     }
     default:

package/plugins/fclt/skills/fclt-evolution/SKILL.md

@@ -20,20 +20,33 @@ fclt ai writeback summarize --by domain
 fclt ai evolve list
 ```
 
-2. Propose only when evidence is strong enough:
+2. Assess proposal readiness before mutating state:
+
+```bash
+fclt ai evolve assess --asset <selector> --json
+```
+
+Use the assessment recommendation as the decision checkpoint:
+
+- `no_mutation`: do not change capability state; ask for a target or evidence.
+- `record_more_writeback`: explain what recurrence would justify evolution and record a new writeback only if there is fresh concrete evidence.
+- `propose`: ask before running the proposal command, then create the smallest target-specific proposal.
+- `review_existing_proposal`: inspect or revise the existing proposal instead of creating a duplicate.
+
+3. Propose only when evidence is strong enough:
 
 ```bash
 fclt ai evolve propose
 ```
 
-3. Draft and inspect:
+4. Draft and inspect:
 
 ```bash
 fclt ai evolve draft EV-00001
 fclt ai evolve review EV-00001
 ```
 
-4. Accept/apply only when scope, target, and evidence are correct:
+5. Accept/apply only when scope, target, and evidence are correct:
 
 ```bash
 fclt ai evolve accept EV-00001
@@ -55,11 +68,13 @@ fclt ai evolve apply EV-00001
 - Ask for approval before applying global instructions, global skills, plugin behavior, or other broad shared surfaces.
 - Reject or park proposals that are stale, duplicated, vague, or unsupported.
 - Use Linear or another task system for executable implementation work that needs owner, priority, or state.
+- A no-op answer must still be useful: include the evidence grade, missing signal, next writeback target, and exact approval boundary.
 
 ## Output
 
 - proposals reviewed
 - repeated signal
+- assessment recommendation
 - proposal created or updated
 - approvals needed
 - apply/reject/no-op rationale

package/src/ai.ts

@@ -163,6 +163,41 @@ export interface AiWritebackGroup {
   summary: string;
 }
 
+export type EvolutionAssessmentRecommendation =
+  | "no_mutation"
+  | "record_more_writeback"
+  | "propose"
+  | "review_existing_proposal";
+
+export interface EvolutionAssessment {
+  scope: AssetScope;
+  projectSlug?: string;
+  projectRoot?: string;
+  asset?: string;
+  target?: string;
+  recommendation: EvolutionAssessmentRecommendation;
+  confidence: ConfidenceLevel;
+  rationale: string;
+  writebackCount: number;
+  sourceWritebacks: string[];
+  kinds: string[];
+  statuses: string[];
+  evidenceCount: number;
+  activeProposalIds: string[];
+  repeatedSignal: boolean;
+  approvalRequired: boolean;
+  suggestedCommands: {
+    readOnly: string[];
+    mutating: string[];
+  };
+  qualityChecklist: {
+    item: string;
+    pass: boolean;
+    note: string;
+  }[];
+  nextAgentInstruction: string;
+}
+
 interface ScopeContext {
   scope: AssetScope;
   projectSlug?: string;
@@ -1047,6 +1082,236 @@ export async function proposeEvolution(args: {
   return proposals.sort((a, b) => a.id.localeCompare(b.id));
 }
 
+const ACTIVE_PROPOSAL_STATUSES: ProposalStatus[] = [
+  "proposed",
+  "drafted",
+  "in_review",
+  "accepted",
+];
+
+function writebackSupportsImmediateProposal(entry: AiWritebackRecord): boolean {
+  return (
+    entry.confidence === "high" &&
+    [
+      "capability_gap",
+      "missing_capability",
+      "missing_context",
+      "stale_asset",
+      "stale_canonical_asset",
+    ].includes(entry.kind)
+  );
+}
+
+function commandAssetArg(asset?: string, target?: string): string {
+  const value = asset ?? target;
+  return value ? ` --asset ${JSON.stringify(value)}` : "";
+}
+
+function assessTargetKey(entry: AiWritebackRecord): string | undefined {
+  return entry.suggestedDestination ?? entry.assetRef;
+}
+
+export async function assessEvolution(args: {
+  homeDir?: string;
+  rootDir: string;
+  asset?: string;
+}): Promise<EvolutionAssessment> {
+  const homeDir = args.homeDir ?? process.env.HOME ?? "";
+  const scopeContext = resolveScopeContext(args.rootDir, homeDir);
+  const filterAsset = args.asset
+    ? await resolveAssetSelection({
+        homeDir,
+        rootDir: args.rootDir,
+        asset: args.asset,
+      })
+    : null;
+  const target = filterAsset?.assetRef ?? args.asset;
+  const writebacks = (await listWritebacks({ homeDir, rootDir: args.rootDir }))
+    .filter((entry) => entry.status !== "dismissed")
+    .filter((entry) => entry.status !== "superseded")
+    .filter((entry) => entry.evidence.length > 0)
+    .filter((entry) => {
+      if (!filterAsset) {
+        return Boolean(assessTargetKey(entry));
+      }
+      return (
+        entry.assetId === filterAsset.assetId ||
+        entry.assetRef === filterAsset.assetRef ||
+        entry.suggestedDestination === filterAsset.assetRef
+      );
+    });
+
+  const groups = new Map<string, AiWritebackRecord[]>();
+  for (const entry of writebacks) {
+    const key = assessTargetKey(entry);
+    if (!key) {
+      continue;
+    }
+    const next = groups.get(key) ?? [];
+    next.push(entry);
+    groups.set(key, next);
+  }
+  const [selectedTarget, selectedWritebacks] =
+    target && groups.has(target)
+      ? ([target, groups.get(target)!] as const)
+      : ([...groups.entries()].sort((a, b) => {
+          if (b[1].length !== a[1].length) {
+            return b[1].length - a[1].length;
+          }
+          return a[0].localeCompare(b[0]);
+        })[0] ?? [target, []]);
+
+  const proposals = await listProposals({ homeDir, rootDir: args.rootDir });
+  const activeProposalIds = proposals
+    .filter((proposal) => ACTIVE_PROPOSAL_STATUSES.includes(proposal.status))
+    .filter((proposal) => {
+      if (!selectedTarget) {
+        return false;
+      }
+      return proposal.targets.includes(selectedTarget);
+    })
+    .map((proposal) => proposal.id)
+    .sort();
+  const sourceWritebacks = selectedWritebacks.map((entry) => entry.id).sort();
+  const kinds = uniqueStrings(selectedWritebacks.map((entry) => entry.kind));
+  const statuses = uniqueStrings(
+    selectedWritebacks.map((entry) => entry.status)
+  );
+  const evidenceCount = selectedWritebacks.reduce(
+    (count, entry) => count + entry.evidence.length,
+    0
+  );
+  const repeatedSignal = selectedWritebacks.length >= 2;
+  const hasStrongSingleSignal = selectedWritebacks.some(
+    writebackSupportsImmediateProposal
+  );
+  const canPropose = selectedWritebacks.length > 0;
+  const shouldPropose = repeatedSignal || hasStrongSingleSignal;
+
+  let recommendation: EvolutionAssessmentRecommendation = "no_mutation";
+  let confidence: ConfidenceLevel = "high";
+  let rationale =
+    "No targetable evidenced writeback signal was found. Do not create a proposal yet.";
+
+  if (activeProposalIds.length > 0) {
+    recommendation = "review_existing_proposal";
+    confidence = "high";
+    rationale = `Existing active proposal${activeProposalIds.length === 1 ? "" : "s"} already cover ${selectedTarget}. Review or revise before creating another proposal.`;
+  } else if (shouldPropose) {
+    recommendation = "propose";
+    confidence = repeatedSignal ? "high" : "medium";
+    rationale = repeatedSignal
+      ? `${selectedTarget} has repeated evidenced signal across ${selectedWritebacks.length} writebacks. A small proposal is justified if the target and scope are correct.`
+      : `${selectedTarget} has one high-confidence writeback that points at a clearly missing or stale capability. A small proposal may be justified after inspecting the target asset.`;
+  } else if (canPropose) {
+    recommendation = "record_more_writeback";
+    confidence = "medium";
+    rationale = `${selectedTarget} has only ${selectedWritebacks.length} evidenced writeback. Prefer recording another concrete recurrence or narrowing the target before proposing evolution.`;
+  }
+
+  const assetArg = commandAssetArg(args.asset, selectedTarget);
+  const readOnly = [
+    "fclt status --json",
+    "fclt ai writeback group --by asset --json",
+    `fclt ai evolve assess${assetArg} --json`,
+    ...(activeProposalIds.length > 0
+      ? activeProposalIds.map((id) => `fclt ai evolve show ${id} --json`)
+      : []),
+  ];
+  const mutating =
+    recommendation === "propose"
+      ? [`fclt ai evolve propose${assetArg} --json`]
+      : canPropose
+        ? [
+            "fclt ai writeback add --kind <kind> --summary <summary> --asset <target> --evidence <type:ref>",
+            `fclt ai evolve propose${assetArg} --json`,
+          ]
+        : [
+            "fclt ai writeback add --kind <kind> --summary <summary> --asset <target> --evidence <type:ref>",
+          ];
+
+  const qualityChecklist = [
+    {
+      item: "targetable asset",
+      pass: Boolean(selectedTarget),
+      note: selectedTarget ?? "No asset or suggested destination was selected.",
+    },
+    {
+      item: "evidence present",
+      pass: evidenceCount > 0,
+      note:
+        evidenceCount > 0
+          ? `${evidenceCount} evidence item${evidenceCount === 1 ? "" : "s"} across selected writebacks.`
+          : "Writebacks without evidence are ignored for evolution.",
+    },
+    {
+      item: "repeated or clearly missing capability",
+      pass: repeatedSignal || hasStrongSingleSignal,
+      note: repeatedSignal
+        ? "Repeated signal is present."
+        : hasStrongSingleSignal
+          ? "Single high-confidence missing/stale capability signal is present."
+          : "Signal is not repeated and does not yet prove a missing or stale capability.",
+    },
+    {
+      item: "no duplicate active proposal",
+      pass: activeProposalIds.length === 0,
+      note:
+        activeProposalIds.length === 0
+          ? "No active proposal targets this asset."
+          : `Active proposals: ${activeProposalIds.join(", ")}.`,
+    },
+    {
+      item: "smallest safe next action",
+      pass: true,
+      note:
+        recommendation === "propose"
+          ? "Draft only the smallest target-specific proposal, then review before apply."
+          : recommendation === "review_existing_proposal"
+            ? "Review or revise the existing proposal instead of creating a duplicate."
+            : recommendation === "record_more_writeback"
+              ? "Record another concrete recurrence before proposing."
+              : "Do not mutate capability state yet.",
+    },
+  ];
+
+  const nextAgentInstruction =
+    recommendation === "propose"
+      ? `Inspect ${selectedTarget}, confirm scope and proposal kind, then ask before running the proposal command. Draft only the smallest change supported by ${sourceWritebacks.join(", ")}.`
+      : recommendation === "review_existing_proposal"
+        ? `Review ${activeProposalIds.join(", ")} and decide whether to revise, accept, reject, or leave it. Do not create a duplicate proposal.`
+        : recommendation === "record_more_writeback"
+          ? "Do not propose yet. Inspect the target if useful, explain what recurrence would change the decision, and record a new writeback only if there is fresh concrete evidence."
+          : "Do not mutate fclt state. Ask for a target asset or gather concrete writeback evidence first.";
+
+  return {
+    scope: scopeContext.scope,
+    projectSlug: scopeContext.projectSlug,
+    projectRoot: scopeContext.projectRoot,
+    asset: args.asset,
+    target: selectedTarget,
+    recommendation,
+    confidence,
+    rationale,
+    writebackCount: selectedWritebacks.length,
+    sourceWritebacks,
+    kinds,
+    statuses,
+    evidenceCount,
+    activeProposalIds,
+    repeatedSignal,
+    approvalRequired:
+      recommendation === "propose" ||
+      recommendation === "review_existing_proposal",
+    suggestedCommands: {
+      readOnly,
+      mutating,
+    },
+    qualityChecklist,
+    nextAgentInstruction,
+  };
+}
+
 export async function listProposals(args?: {
   homeDir?: string;
   rootDir: string;
@@ -1759,7 +2024,7 @@ function aiHelp(): string {
 
 Usage:
   fclt ai writeback <add|list|show|dismiss|promote> [args...]
-  fclt ai evolve <propose|list|show|draft|review|accept|reject|supersede|apply> [args...]
+  fclt ai evolve <assess|propose|list|show|draft|review|accept|reject|supersede|apply> [args...]
 `;
 }
 
@@ -1781,6 +2046,7 @@ function evolveHelp(): string {
   return `fclt ai evolve
 
 Usage:
+  fclt ai evolve assess [--asset <selector>] [--json]
   fclt ai evolve propose [--asset <selector>] [--json]
   fclt ai evolve list [--json]
   fclt ai evolve show <id> [--json]
@@ -2001,6 +2267,31 @@ async function evolveCommand(argv: string[]) {
   });
 
   try {
+    if (sub === "assess") {
+      const assessment = await assessEvolution({
+        rootDir,
+        asset: parseStringFlag(commandArgs, "--asset"),
+      });
+      if (commandArgs.includes("--json")) {
+        console.log(JSON.stringify(assessment, null, 2));
+        return;
+      }
+      console.log(`recommendation: ${assessment.recommendation}`);
+      console.log(`target: ${assessment.target ?? "none"}`);
+      console.log(`confidence: ${assessment.confidence}`);
+      console.log(`rationale: ${assessment.rationale}`);
+      console.log(
+        `writebacks: ${assessment.writebackCount}${
+          assessment.sourceWritebacks.length > 0
+            ? ` (${assessment.sourceWritebacks.join(", ")})`
+            : ""
+        }`
+      );
+      console.log(`approval required: ${assessment.approvalRequired}`);
+      console.log(`next: ${assessment.nextAgentInstruction}`);
+      return;
+    }
+
     if (sub === "propose") {
       const proposals = await proposeEvolution({
         rootDir,

package/src/builtin-assets.ts

@@ -2,10 +2,10 @@
 
 export const BUILTIN_OPERATING_MODEL_FILES = JSON.parse(
   // biome-ignore lint/suspicious/noTemplateCurlyInString: Built-in templates intentionally contain literal render placeholders.
-  '{"agents/evolution-planner/agent.toml":"name = \\"evolution-planner\\"\\ndescription = \\"Turn repeated writeback into concrete capability proposals.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou plan capability evolution.\\n\\nPrioritize:\\n- smallest useful change\\n- correct target asset type\\n- correct target scope\\n- evidence that justifies the change\\n- repeated writeback clusters or clearly missing capabilities, not isolated preferences\\n\\nProposal kinds you should consider first:\\n- update_asset\\n- create_asset\\n- extract_snippet\\n- add_skill\\n- promote_asset\\n\\nDefault to project scope when the pattern is repo-local.\\nPromote to global only when reuse is demonstrated and pollution risk is low.\\n\\nReturn concise proposals ordered by expected leverage, including:\\n- proposal kind\\n- target asset\\n- target scope\\n- why this is the smallest durable change\\n- source writeback ids or evidence summary\\n- approval risk and verification path\\n\\nDo not escalate to evolution when a single writeback is enough.\\nDo not use evolution as a substitute for executable task tracking when the main need is owner, priority, state, or implementation follow-through.\\nDo not globalize private, repo-specific, or speculative guidance.\\n\\"\\"\\"\\n","agents/integration-auditor/agent.toml":"name = \\"integration-auditor\\"\\ndescription = \\"Find where local success can still fail system-wide.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou audit integration risk.\\n\\nPrioritize:\\n- hidden dependencies\\n- rollout hazards\\n- operational constraints\\n- gaps between local verification and real system behavior\\n- packaged, installed, rendered, or synced paths that differ from source behavior\\n- parallel execution and state-location risks\\n- privacy boundaries between global, project, generated, and machine-local state\\n\\nReturn concise findings ordered by impact. For each finding include:\\n- boundary at risk\\n- why the current evidence is or is not enough\\n- strongest next verification step\\n- whether the fix belongs in code, docs, a task, or capability evolution\\n\\"\\"\\"\\n","agents/scope-promoter/agent.toml":"name = \\"scope-promoter\\"\\ndescription = \\"Decide whether learning belongs at project or global scope.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou decide scope.\\n\\nPrioritize:\\n- project specificity\\n- cross-project reuse potential\\n- pollution risk from globalizing too early\\n- private or repo-specific details that must not move into global capability\\n- whether a smaller snippet, instruction, skill, or agent should be promoted instead of a broad doc\\n\\nWhen recommending promotion, make the standard path explicit:\\n- keep the source capability in project scope until promotion is approved\\n- create a reviewable global proposal\\n- do not treat promotion as implicit apply\\n\\nReturn concise decisions with:\\n- recommended scope\\n- target asset or smallest unit\\n- evidence for reuse\\n- privacy/pollution risk\\n- promotion path or no-op rationale\\n\\"\\"\\"\\n","agents/writeback-curator/agent.toml":"name = \\"writeback-curator\\"\\ndescription = \\"Turn noisy outcomes into high-signal writeback.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou curate durable writeback.\\n\\nPrioritize:\\n- repeated failures\\n- repeated wins\\n- stale guidance\\n- missing capability edges\\n- tool, skill, MCP, plugin, automation, or instruction friction that repeatedly slows work down\\n\\nFor each recommendation, prefer returning:\\n- suggested writeback kind\\n- best target asset or destination\\n- best scope (`project` or `global`)\\n- the evidence that justifies recording it\\n- whether the signal is enough for writeback only, task tracking, or evolution\\n\\nDo not emit low-signal noise.\\nIf the learning is repo-specific, keep it project-scoped by default.\\nWhen the signal is already strong and the target is clear, prefer recommending direct writeback capture rather than abstract advice.\\nWhen the issue is executable tooling work, recommend task tracking for the fix and writeback only for the reusable operating-model learning.\\nWhen the issue contains private project details, preserve the general learning without copying private details into a global asset.\\n\\"\\"\\"\\n","instructions/CAPABILITY_COMPOSITION.md":"---\\ndescription: \\"Compose small capability units across global and project roots, then evolve the smallest affected unit.\\"\\ntags: [\\"facult\\", \\"composition\\", \\"refs\\", \\"snippets\\", \\"instructions\\"]\\n---\\n\\n# Capability Composition\\n\\nUse `fclt` capability as small units that can be composed, inspected, rendered, and evolved independently.\\n\\nThe main units are:\\n\\n- instructions: standalone markdown doctrine such as language preferences, verification rules, or review standards\\n- snippets: small markdown partials inserted into one or more rendered docs\\n- skills: task-specific workflows with `SKILL.md`\\n- agents: focused role manifests\\n- MCP definitions: tool interfaces and their safe auth shape\\n- automations: scheduled review or maintenance loops\\n- tool rules/config: tool-specific defaults and policy\\n\\n## Composition Rules\\n\\n- Keep reusable doctrine in `instructions/`.\\n- Keep repeated paragraphs or policy blocks in `snippets/`.\\n- Keep workflow execution in `skills/`.\\n- Keep persona or delegation behavior in `agents/`.\\n- Keep tool wiring in `mcp/` and `tools/<tool>/`.\\n- Compose broad agent docs from refs and snippets instead of copying text by hand.\\n- Prefer one narrow reusable unit over one large instruction file that mixes unrelated domains.\\n\\nExamples:\\n\\n- `@ai/instructions/LANGUAGE.md` for a user-owned language/tooling preference.\\n- `@ai/instructions/REVIEW.md` for a user-owned review standard.\\n- `@project/instructions/TESTING.md` for repo-specific test policy.\\n- `<!-- fclty:global/codex/baseline -->` for a shared rendered block.\\n\\n## Scope\\n\\nUse global scope for capability that should follow the user across projects.\\n\\nUse project scope for capability that belongs to a repo, team workflow, architecture, or local test harness.\\n\\nPromote project capability to global only when repeated evidence shows reuse across projects. Do not globalize a project quirk just because it worked once.\\n\\n## Writeback and Evolution\\n\\nTarget the smallest affected unit.\\n\\n- If a paragraph is reused in several rendered docs, target the snippet.\\n- If a domain rule is wrong, target the instruction.\\n- If a workflow is incomplete, target the skill.\\n- If a delegated role is unclear, target the agent.\\n- If a tool interface is missing or unsafe, target the MCP or tool config.\\n- If a scheduled review loop is noisy or missing context, target the automation.\\n\\nGood writeback targets are graph-backed selectors when possible:\\n\\n```bash\\nfclt ai writeback add --kind missing_context --summary \\"Language guidance did not cover test runner selection.\\" --asset instruction:LANGUAGE\\nfclt ai writeback add --kind reusable_pattern --summary \\"Project test policy should become a shared verification snippet.\\" --asset @project/instructions/TESTING.md\\nfclt ai writeback add --kind bad_default --summary \\"The review automation escalated one-off preferences.\\" --asset automation:evolution-review\\n```\\n\\nUse `fclt ai evolve ...` only after repeated signal, a clearly missing capability, or a stale canonical asset points at a concrete change. Prefer the smallest valid proposal kind: `update_asset`, `create_asset`, `extract_snippet`, `add_skill`, or `promote_asset`.\\n\\n## Agent Defaults\\n\\nWhen an agent sees a repeated language, framework, or test preference, it should not bury that in chat. It should identify whether the durable unit is:\\n\\n- a global instruction\\n- a project instruction\\n- a snippet reused by rendered docs\\n- a skill workflow\\n- a project-to-global promotion candidate\\n\\nThen it should record writeback against that unit, or draft a proposal when the evidence is already strong enough.\\n","instructions/EVOLUTION.md":"---\\ndescription: Turn repeated signal into concrete capability changes.\\ntags: [facult, evolution, writeback]\\n---\\n\\n# Evolution\\n\\nUse writeback and evolution to improve the AI operating layer itself.\\n\\nEvolution is the synthesis and change side of the feedback loop. It turns accumulated writebacks, repeated tool friction, stale canonical assets, or clearly missing capability into small reviewable changes to instructions, skills, snippets, agents, or other markdown canonical assets.\\n\\nUse capability composition when choosing the target. Instructions, snippets, skills, agents, MCP/tool config, and automations are separate units. Target the smallest unit that actually needs to change instead of rewriting a broad agent doc.\\n\\n## When To Record Writeback\\n\\nRecord writeback when one of these is true:\\n\\n- the same failure repeats\\n- the same success pattern repeats\\n- guidance is stale or missing\\n- a prompt or loop has to be restated often\\n- a project-specific pattern looks reusable\\n\\nDo not record low-signal noise:\\n\\n- one-off annoyance with no reuse value\\n- generic \\"could be better\\" commentary\\n- duplicate observations with no new evidence\\n\\nThe intended default is that agents record strong writebacks themselves when the signal is clear enough, rather than only recommending that a user do it manually later.\\n\\nDo not wait for a weekly review to preserve high-signal evidence. Do wait for repeated evidence or a clearly missing capability before drafting a proposal.\\n\\n## Scope\\n\\nChoose `project` scope when the learning depends on:\\n\\n- repo architecture\\n- team workflow\\n- project tooling\\n- local testing or verification behavior\\n\\nChoose `global` scope when the learning is reusable across projects.\\n\\nPromote from project to global only after repeated reuse or strong evidence.\\n\\n## Writeback Kinds\\n\\nCommon kinds:\\n\\n- `weak_verification`\\n- `false_positive`\\n- `missing_context`\\n- `reusable_pattern`\\n- `capability_gap`\\n- `bad_default`\\n\\nEvery good writeback should try to include:\\n\\n- a concrete summary\\n- the best target asset if known\\n- the right scope\\n- domain or tags when useful\\n\\nGood target examples:\\n\\n- `instruction:LANGUAGE` when shared language/tooling guidance is stale or missing\\n- `@project/instructions/TESTING.md` when repo test policy needs project-scoped evolution\\n- `snippet:global/policy/review` when a repeated rendered block should be fixed or extracted\\n- `skill:capability-evolution` when a workflow skill is missing steps or examples\\n- `automation:evolution-review` when the scheduled review loop is noisy or incomplete\\n\\n## Operator Flow\\n\\nTypical workflow:\\n\\n```bash\\nfclt ai writeback add --kind weak_verification --summary \\"Checks were too shallow\\" --asset instruction:VERIFICATION\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve propose\\nfclt ai evolve draft EV-00001\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\nUse `fclt ai evolve draft <id> --append \\"...\\"` to revise a draft while preserving draft history.\\n\\nReview surfaces:\\n\\n- open `~/.ai/writebacks/` and `~/.ai/evolution/` in a Markdown editor for frontmatter-rich global and project-scoped review artifacts\\n- `fclt status --json` for queue/proposal paths, review artifact paths, counts, and active scope\\n- `fclt ai writeback list|show|group|summarize` for raw and clustered signal\\n- `fclt ai evolve list|show|review` for proposal state without applying changes\\n- `fclt templates init automation learning-review` for recurring capture/review\\n- `fclt templates init automation evolution-review` for recurring proposal review\\n- `fclt templates init automation tool-call-audit` for repeated tool-friction review\\n\\nEvolution proposal metadata, markdown drafts, patch artifacts, writeback queues,\\nand journals are runtime state. `fclt` stores JSON queues, proposal records,\\ndraft refs, patches, and journals in machine-local `fclt` state. It mirrors\\nhuman-readable review artifacts into global `~/.ai/writebacks/...` and\\n`~/.ai/evolution/...`, including project-scoped artifacts under\\n`projects/<slug-hash>/` with cwd/project metadata in frontmatter. Canonical\\nassets in `~/.ai` or `<repo>/.ai` should only change when a proposal is applied.\\n\\n## Default Agent Behavior\\n\\nUse the smallest action that fits the signal:\\n\\n1. record one strong writeback when there is a clear durable learning\\n2. use `writeback-curator` when the target, kind, or scope is ambiguous\\n3. use `capability-evolution` or `evolution-planner` when repeated signal should become a proposal\\n4. do not draft or apply proposals just because a writeback exists; require repeated evidence or a clearly missing capability\\n\\nAvoid creating writeback/evolution noise for one-off nits, vague preferences, or speculative ideas without evidence.\\n\\nWhen the friction is executable product/tooling work that needs ownership,\\npriority, state, or implementation follow-through, create or update a real task\\nsystem item instead of forcing it into capability evolution. Use evolution for\\nthe reusable operating-layer change.\\n\\n## Proposal Kinds\\n\\nCurrent supported proposal kinds:\\n\\n- `update_asset`\\n- `create_asset`\\n- `extract_snippet`\\n- `add_skill`\\n- `promote_asset`\\n\\nUse the smallest durable change that fits the evidence.\\n\\nExamples:\\n\\n- `update_asset`: fix a stale instruction, snippet, agent, or automation markdown asset.\\n- `create_asset`: add a missing instruction such as `LANGUAGE.md` or `REVIEW.md`.\\n- `extract_snippet`: move repeated guidance out of several docs into one snippet.\\n- `add_skill`: create a workflow when instructions are not enough.\\n- `promote_asset`: move a proven project instruction/snippet/skill toward global reuse.\\n\\n## Review And Apply Rules\\n\\n- draft before apply\\n- accept before apply\\n- prefer the smallest safe change\\n- keep reviewable evidence tied to source writebacks\\n- do not globalize project behavior too early\\n- do not apply high-risk global instruction, skill, plugin, or shared-tool changes without explicit review/approval\\n\\nApply is for markdown canonical assets only. If the target is wrong, revise the proposal rather than forcing it through.\\n","instructions/INTEGRATION.md":"---\\ndescription: Detect where local success can still fail at integration boundaries.\\ntags: [facult, integration, verification]\\n---\\n\\n# Integration\\n\\nDistinguish local correctness from system correctness. Check hidden dependencies, rollout order, and operational constraints before calling work done.\\n\\n## When To Use\\n\\nUse this when a local green signal may still fail at a boundary:\\n\\n- code passes focused tests but has not been checked against the real workflow\\n- docs are correct in isolation but may send agents to a stale command or path\\n- a tool command works locally but may fail under packaged, sandboxed, or parallel execution\\n- a capability change renders into one agent tool but not another\\n- a project-local improvement may collide with global defaults or managed output\\n- a migration, release, or rollout has ordering constraints\\n\\n## Integration Questions\\n\\nAsk the smallest set that matches the risk:\\n\\n- What consumes this output?\\n- What state does this depend on?\\n- What happens if two agents or commands run this at the same time?\\n- Does the packaged/released path behave like the source checkout?\\n- Does the project-scoped path avoid leaking into global or public surfaces?\\n- Does the global path avoid overwriting tool-native or user-edited state?\\n- Is rollback or recovery clear if the integration fails?\\n\\n## Evidence\\n\\nPrefer evidence that crosses the boundary that could fail:\\n\\n- run the installed CLI, packaged binary, or generated artifact when source tests are not enough\\n- inspect rendered output when changing snippets, refs, or agent docs\\n- use temp roots and clean homes for setup, upgrade, and sync behavior\\n- verify review artifacts land in global `~/.ai/writebacks` or `~/.ai/evolution`, not repo-local private state\\n- check release, package, or plugin surfaces when the change affects users outside the repo\\n\\n## Output\\n\\nReturn concise findings ordered by risk:\\n\\n- boundary checked\\n- evidence used\\n- remaining assumption\\n- fix or follow-up if local correctness does not prove system correctness\\n\\nRecord writeback when the same integration boundary repeatedly fails, the verification loop is too weak, or a missing skill/tool would make the boundary easier to check next time.\\n","instructions/LEARNING_AND_WRITEBACK.md":"---\\ndescription: Preserve durable signal and record writeback when the operating layer should learn.\\ntags: [facult, learning, writeback]\\n---\\n\\n# Learning And Writeback\\n\\nUse this when work produces a durable decision, failure, success pattern, or missing guardrail that should outlive the current task.\\n\\nThis is the capture side of the feedback loop. The goal is to let normal agent work produce reusable signal without requiring a human to manually restate every friction point later.\\n\\n## Default Behavior\\n\\nThe normal path should be agent-driven.\\n\\nIf you can clearly answer:\\n\\n- what was learned\\n- why it matters\\n- where it should land\\n- whether it belongs in `project` or `global`\\n\\nthen record the writeback instead of only suggesting that someone should do it later.\\n\\nUse:\\n\\n```bash\\nfclt ai writeback add --kind <kind> --summary \\"<summary>\\" --asset <asset-selector>\\n```\\n\\nThe writeback queue is runtime state, not canonical source. `fclt` stores JSON\\nqueue state in machine-local `fclt` state so sandboxed agents can record durable\\nfriction without mutating canonical assets unless an evolution proposal is later\\nreviewed and applied.\\n\\nEvery writeback also refreshes a Markdown review artifact under the global\\n`~/.ai/writebacks/...` tree. Global signal lands in `~/.ai/writebacks/global/`;\\nproject-scoped signal lands in `~/.ai/writebacks/projects/<slug-hash>/` with\\nfrontmatter for scope, project root, cwd, target asset, status, tags, evidence,\\nand timestamps. Do not write writeback review artifacts into a repo-local `.ai`;\\nrepo-local state should contribute project metadata and evidence, not bundled\\nprivate review files.\\n\\nProject-scoped writebacks should usually be recorded from the repo that produced\\nthe evidence. Global writebacks should be reserved for shared doctrine, shared\\nskills, shared agents, tool behavior, or cross-project capability gaps.\\n\\nTarget the smallest composable unit that explains the friction:\\n\\n- instruction: domain guidance, preferences, verification rules, or review doctrine\\n- snippet: repeated markdown block used by more than one rendered doc\\n- skill: workflow execution steps or examples\\n- agent: delegated role behavior\\n- MCP/tool config: tool interface, auth shape, or rendered integration\\n- automation: scheduled review loop, cadence, prompt, or memory\\n\\n## Record Writeback When\\n\\n- the same failure or weak loop appears again\\n- a reusable success pattern shows up\\n- guidance is clearly stale or missing\\n- a repo-local behavior probably belongs in project capability\\n- a cross-project behavior probably belongs in global capability\\n- a skill, tool, MCP, plugin, automation, or instruction gap repeatedly slows work down\\n- an agent has to restate the same workaround, verification rule, or review rule\\n- a repeated preference should become an atomic user-owned instruction or project-specific testing policy\\n\\n## Do Not Record Writeback For\\n\\n- one-off annoyance with no durable value\\n- weak commentary with no target\\n- speculative ideas without evidence\\n- duplicate noise with no new signal\\n\\n## Follow Through\\n\\n- prefer one strong writeback over many weak ones\\n- mention the writeback id when summarizing what changed\\n- escalate to `capability-evolution` or `fclt ai evolve ...` only when the signal is repeated or clearly points at a durable capability change\\n- use `fclt ai writeback group --by asset` or `fclt ai writeback summarize --by domain` to review accumulated signal before proposing broad changes\\n- use scheduled `learning-review`, `evolution-review`, or `tool-call-audit` automations when the signal should be reviewed in the background\\n","instructions/PROJECT_CAPABILITY.md":"---\\ndescription: Decide what belongs in repo-local .ai versus the global store.\\ntags: [facult, project, scope]\\n---\\n\\n# Project Capability\\n\\nPrefer project scope when the guidance depends on repo architecture, team workflow, or colocated tooling. Promote to global only after repeated cross-project reuse.\\n\\n## Project First\\n\\nDefault to `<repo>/.ai` when the capability is about:\\n\\n- local architecture\\n- repo-specific testing or verification\\n- team conventions\\n- project tools and workflows\\n- product, customer, deployment, or operational context tied to one repo\\n- examples that would leak private or irrelevant detail if copied globally\\n\\nProject capability should travel with the repo when it is safe to commit. Generated state, machine-local runtime state, secrets, and review queues should not travel with it.\\n\\n## Global Scope\\n\\nUse `~/.ai` when the capability should follow the user across projects:\\n\\n- general verification standards\\n- reusable work-unit, feedback-loop, or writeback doctrine\\n- user-owned language/tool preferences that are safe to share across repos\\n- cross-project skills or agents\\n- MCP/tool integration patterns that are not tied to one repo\\n\\nGlobal capability should be broadly useful and low-noise. A global rule that only helps one project is usually a project rule.\\n\\n## Review Artifacts\\n\\nProject-scoped writebacks and evolution proposals use the project as evidence, but their Markdown review artifacts are mirrored under global `~/.ai/writebacks/projects/<slug-hash>/` and `~/.ai/evolution/projects/<slug-hash>/`.\\n\\nDo not create repo-local `writebacks/` or `evolution/` review trees inside `<repo>/.ai`. Keep private review state out of the repo while preserving project metadata in the global review artifact frontmatter.\\n\\n## Promote Carefully\\n\\nPromote to `~/.ai` only when:\\n\\n- the same pattern succeeds in more than one repo\\n- the capability is not coupled to local architecture\\n- the global version will not create noise for unrelated projects\\n- private examples can be removed or generalized without losing the rule\\n- the target global unit is smaller than a broad rewrite\\n\\nUse:\\n\\n```bash\\nfclt ai evolve promote EV-00001 --to global --project\\n```\\n\\nThat creates a new global proposal for review. It does not auto-apply the promotion.\\n\\n## Decision Checklist\\n\\nChoose project when the answer depends on \\"this repo\\". Choose global when the answer would still be correct after removing the repo name.\\n\\nIf unsure:\\n\\n1. keep the asset project-scoped\\n2. record writeback with the reason it might generalize\\n3. wait for another project or repeated evidence\\n4. promote through a reviewable proposal, not by copying files by hand\\n","instructions/WORK_UNITS.md":"---\\ndescription: \\"Define work units so agent tasks have a clear goal, evidence path, artifact, and writeback target.\\"\\ntags: [\\"work-units\\", \\"planning\\", \\"verification\\", \\"writeback\\"]\\n---\\n\\n# Work Units\\n\\nA work unit is the smallest coherent unit of agent work that can be understood, verified, and preserved.\\n\\nIt is not just the user\'s latest sentence. It is the operational shape around that sentence: what is being changed, why it matters, what evidence is needed, what artifact should remain, and how future agents should benefit from the result.\\n\\nUse work units for ordinary work, not only for capability updates. Coding changes, research answers, documentation edits, operational triage, setup repair, design reviews, and capability evolution all benefit from the same shape when the task has real uncertainty or risk.\\n\\n## Minimum Contract\\n\\nA well-formed work unit names:\\n\\n- goal: the outcome the user needs\\n- acceptance criteria: what must be true when the work is done\\n- required context: source files, docs, systems, messages, or prior decisions needed for correctness\\n- constraints: permissions, privacy, compatibility, deadlines, ownership, or scope limits\\n- signals or evidence: checks that can confirm progress or falsify assumptions\\n- output artifact: code, docs, proposal, issue, note, draft, or report\\n- verification path: commands, review surfaces, manual checks, or source-of-truth reads\\n- writeback target: where durable learning belongs if the work teaches something reusable\\n\\nIf one of these is missing and the gap blocks correctness, surface the gap early and recover it before moving faster.\\n\\nFor low-risk one-step work, keep the contract implicit. For ambiguous, high-impact, cross-tool, stateful, or multi-step work, make the contract explicit before executing.\\n\\n## Why It Exists\\n\\nWork-unit framing prevents shallow completion. It helps agents avoid:\\n\\n- changing files before understanding the target\\n- treating a weak green signal as proof\\n- losing reusable learning in chat\\n- creating duplicate tasks or proposals\\n- turning one-off preferences into global rules\\n- pushing project-specific details into global capability\\n- producing output faster than the system can review, integrate, or learn from it\\n\\nThe point is not paperwork. The point is to attach machine work to intent, context, evidence, and memory so that useful learning can change future work instead of disappearing into chat history.\\n\\n## How To Use It\\n\\nFor simple tasks, keep the work unit implicit but still verify the result.\\n\\nFor ambiguous, high-impact, or multi-step tasks, make the work unit explicit before executing. A compact form is enough:\\n\\n```text\\nGoal:\\nAcceptance:\\nContext:\\nConstraints:\\nEvidence:\\nArtifact:\\nVerification:\\nWriteback:\\n```\\n\\nUse the smallest framing that makes the task correct. Do not turn every request into paperwork.\\n\\n## Examples\\n\\nCoding:\\n\\n```text\\nGoal: fix the failing login test\\nAcceptance: test passes and no auth regression is introduced\\nContext: failing test output, auth middleware, recent commits\\nConstraints: preserve public API\\nEvidence: focused test, relevant integration test\\nArtifact: code diff and concise summary\\nVerification: command output and changed behavior\\nWriteback: only if the failure exposes stale test or auth guidance\\n```\\n\\nResearch:\\n\\n```text\\nGoal: answer a source-backed product question\\nAcceptance: answer cites current primary sources\\nContext: user question, relevant docs, dates\\nConstraints: distinguish verified facts from inference\\nEvidence: source links and quotes within fair-use limits\\nArtifact: answer or research note\\nVerification: source freshness and consistency check\\nWriteback: durable note if the finding will recur\\n```\\n\\nCapability evolution:\\n\\n```text\\nGoal: decide whether repeated writebacks justify a proposal\\nAcceptance: proposal exists only if evidence repeats or a capability is clearly missing\\nContext: grouped writebacks, target asset, current canonical guidance\\nConstraints: avoid global noise and private leakage\\nEvidence: writeback IDs and affected work units\\nArtifact: accepted proposal, rejected proposal, or no-op note\\nVerification: proposal kind, scope, target, and review artifact\\nWriteback: only for new meta-learning about the evolution process\\n```\\n\\n## Writeback\\n\\nWhen the work reveals durable friction, missing capability, stale guidance, or a repeatable workflow, prefer one strong writeback over many weak ones.\\n\\nUse `fclt ai writeback add ...` when the target asset, scope, and evidence are clear. Use `fclt ai evolve ...` only when repeated signal supports a concrete proposal.\\n","skills/capability-evolution/SKILL.md":"---\\ndescription: Convert repeated writeback into concrete fclt capability proposals.\\ntags: [facult, evolution, writeback]\\n---\\n\\n# capability-evolution\\n\\n## When To Use\\nUse this skill when the same missing guidance, weak loop, or recurring win appears often enough that the AI system itself should probably change.\\n\\nDo not wait for a human operator by default if the signal is already clear and the environment permits local AI runtime state to be updated.\\n\\nUse writeback first when the signal is useful but not yet repeated. Use evolution when accumulated writebacks, repeated tool friction, or a clearly missing capability point at a specific target asset or new capability.\\n\\nThe goal is a governed feedback loop: work creates evidence, evidence produces writeback, repeated writeback becomes a small reviewed proposal, and accepted proposals change future agent behavior.\\n\\n## Scope Decision\\n\\nChoose `project` when the behavior depends on repo-local architecture or workflow.\\n\\nChoose `global` when the behavior is broadly reusable.\\n\\nIf unsure, start at project scope and promote later with evidence.\\n\\nReject global scope when the proposal depends on private examples, one repo\'s architecture, a single user\'s temporary preference, or a workflow that has not repeated.\\n\\n## Working Flow\\n\\n1. Read current writebacks and existing proposals.\\n2. Group or summarize repeated signal by asset, kind, and scope.\\n3. Check the current target asset before proposing a change.\\n4. Choose the smallest valid proposal kind.\\n5. Draft the proposal with evidence and intended target.\\n6. Accept only after the target and scope are correct.\\n7. Apply only when the markdown target is the intended canonical asset.\\n\\nUse:\\n\\n```bash\\nfclt ai writeback add ...\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve propose\\nfclt ai evolve draft EV-00001\\nfclt ai evolve draft EV-00001 --append \\"tighten the rule with a concrete verification step\\"\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\nFor background review loops, use:\\n\\n```bash\\nfclt templates init automation learning-review\\nfclt templates init automation evolution-review\\nfclt templates init automation tool-call-audit\\n```\\n\\nIf there is not yet enough repeated signal for evolution, record the writeback and stop there.\\n\\nDo not create a proposal only to preserve an idea. Preserve the idea as writeback, notes, or task tracking unless it has enough evidence to change capability.\\n\\n## Proposal Kind Selection\\n\\n- `update_asset` for tightening existing guidance\\n- `create_asset` for missing instructions or docs\\n- `extract_snippet` for reusable partial guidance\\n- `add_skill` for reusable workflow instruction\\n- `promote_asset` for project-to-global promotion\\n\\nUse task tracking instead of evolution when the main work is an executable tool or product fix that needs an owner, priority, state, or delivery plan. Use evolution for the reusable instruction, skill, or operating-model change that should survive that fix.\\n\\n## Review Criteria\\n\\nBefore accept/apply, verify:\\n\\n- evidence is repeated or the missing capability is obvious\\n- the proposal targets the smallest affected unit\\n- project/global scope is correct\\n- private or project-specific examples are not leaking into global assets\\n- the patch changes canonical markdown assets, not generated runtime state\\n- the resulting behavior can be verified by reading, rendering, indexing, or running the relevant command\\n\\n## Output Contract\\n- repeated signal\\n- proposed asset change\\n- target scope\\n- evidence\\n- smallest useful next step\\n- approval or no-op rationale\\n","skills/project-operating-layer-design/SKILL.md":"---\\ndescription: Design or improve a repo-local .ai operating layer.\\ntags: [facult, project, design]\\n---\\n\\n# project-operating-layer-design\\n\\n## When To Use\\nUse this skill when a project needs its own `.ai/` structure, repo-specific instructions, or local bootstrap guidance.\\n\\nUse it when:\\n\\n- a repo has recurring agent friction that should not become global doctrine\\n- setup or verification steps are repeatedly rediscovered\\n- project skills, agents, MCP definitions, or snippets need a stable source of truth\\n- a repo needs policy for what may be rendered into tool homes\\n- a project should contribute writeback/evolution evidence without committing private review artifacts\\n\\nDo not use it to copy a user\'s private global preferences into a public repo.\\n\\n## Design Rules\\n\\n- Start from the repo\'s real workflows, commands, and risk boundaries.\\n- Keep project-specific guidance in `<repo>/.ai`.\\n- Keep generated state, queues, review artifacts, and local machine config out of the repo.\\n- Prefer a few high-leverage instructions or skills over a large generic dump.\\n- Use snippets only for blocks that are reused or independently evolvable.\\n- Make verification and integration paths explicit enough for future agents to run.\\n- Add sync policy only for assets that should render into repo-local tool outputs.\\n\\n## Working Flow\\n\\n1. Inventory existing repo guidance and tool files.\\n2. Identify repeated friction from recent work, issues, reviews, or writebacks.\\n3. Separate project-specific behavior from global/user-owned behavior.\\n4. Propose a minimal `.ai` layout.\\n5. Add or update the smallest useful assets.\\n6. Verify the graph/index and any rendered output.\\n7. Record writeback for reusable learnings that should evolve later.\\n\\n## Output Contract\\n- recommended `.ai/` layout\\n- what stays project-local\\n- what stays global\\n- what should remain generated runtime output only\\n- sync/rendering policy\\n- verification path\\n- privacy or commit-safety risks\\n","snippets/global/baseline.md":"- Preserve existing user changes unless asked to rewrite them.\\n- Prefer small, reviewable diffs and verify meaningful changes before claiming success.\\n- State constraints, risks, and follow-up steps directly.\\n","snippets/global/core/feedback-loops.md":"- For any task, identify the highest-signal feedback loops available.\\n- Prefer loops that can verify progress, falsify weak assumptions, and expose failure early.\\n- Do not rely on a single shallow positive signal if stronger verification exists.\\n- If the available loop is stale, weak, noisy, or easy to game, improve it or say what is missing.\\n- When useful, leave behind a stronger loop than the one you started with.\\n- Treat verification, evaluation, and writeback as part of the work, not cleanup after it.\\n- For work-unit clarification, read ${refs.work_units}.\\n- For verification guidance, read ${refs.verification}.\\n- For integration risk, read ${refs.integration}.\\n- For learning and writeback, read ${refs.learning_writeback}.\\n- For deeper guidance, read ${refs.feedback_loops}.\\n","snippets/global/core/verification.md":"- Treat verification as part of the work, not a final checkbox.\\n- Prefer the strongest available proof that matches the real risk.\\n- Make clear what has actually been verified and what remains assumed.\\n- Distrust shallow green signals when stronger checks are available.\\n- If the current harness is stale, weak, or misleading, say so and improve it where possible.\\n- For deeper guidance, read ${refs.verification}.\\n","snippets/global/core/work-units.md":"- Treat every task as a work unit, not just a request.\\n- A work unit should have a goal, acceptance criteria, required context, constraints, signals or evidence, an output artifact, a verification path, and a writeback target when the work teaches something reusable.\\n- If any of those are missing and the gap blocks correctness, surface it early and try to recover it.\\n- Prefer making the work unit more explicit before increasing execution speed.\\n- If the task is vague, ambiguous, or overloaded, narrow it before acting.\\n- Treat work-unit framing as generally applicable to coding, research, writing, operations, setup, debugging, and capability evolution.\\n- For deeper guidance, read ${refs.work_units}.\\n","snippets/global/core/writeback.md":"- Do not end at output if something important was learned.\\n- Preserve decisions, failures, successes, and reusable signal when they will improve future work.\\n- Prefer writing to a real destination over leaving knowledge in chat.\\n- When useful, leave behind better docs, tests, evals, prompts, notes, or follow-up tasks.\\n- When a high-signal learning clearly points at a canonical asset or durable destination, record a writeback before ending the task.\\n- Prefer one strong writeback over many weak ones.\\n- If you can name the target asset, the expected scope, and the actual signal, use `fclt ai writeback add ...` instead of merely mentioning that writeback would be useful.\\n- If repeated signal is already accumulating, use the `capability-evolution` skill or `fclt ai evolve ...` flow to turn it into a reviewable proposal.\\n- For deeper guidance, read ${refs.learning_writeback}.\\n","snippets/templates/agents-global.md":"# Global Agent Instructions\\n\\nThis template materializes as `AGENTS.global.md` when the operating-model pack is\\ninstalled. It should stay small and composed from snippets. Put detailed\\ndoctrine in instructions, workflow execution in skills, and local/private\\npreferences in user-owned or project-owned assets outside the public pack.\\n\\n## Working mode\\n\\n<!-- fclty:global/baseline -->\\n<!-- /fclty:global/baseline -->\\n\\n<!-- fclty:global/core/work-units -->\\n<!-- /fclty:global/core/work-units -->\\n\\n<!-- fclty:global/core/feedback-loops -->\\n<!-- /fclty:global/core/feedback-loops -->\\n\\n<!-- fclty:global/core/verification -->\\n<!-- /fclty:global/core/verification -->\\n\\n<!-- fclty:global/core/writeback -->\\n<!-- /fclty:global/core/writeback -->\\n\\n## Shared instruction sources\\n\\n- For work-unit definition and scope clarification, read ${refs.work_units}.\\n- For identifying, improving, and validating feedback loops, read ${refs.feedback_loops}.\\n- For verification and anti-false-positive checks, read ${refs.verification}.\\n- For checking integration boundaries, read ${refs.integration}.\\n- For learning, decisions, and writeback, read ${refs.learning_writeback}.\\n- For capability evolution, proposal kinds, and `facult ai` workflow, read ${refs.evolution}.\\n- For deciding whether something belongs in global or project scope, read ${refs.project_capability}.\\n- Add private language, coding, or writing refs in local config only when they belong to the user\'s own operating layer.\\n\\n## Layering\\n\\n- Treat this file as the global baseline.\\n- Treat repo-level `AGENTS.md` files as more specific additions layered after this file.\\n- Repo-level files may add or refine project-specific behavior, but they should not weaken global defaults for rigor, verification, or writeback discipline.\\n- If a closer `AGENTS.override.md` exists, follow it as the most specific instructions file in that directory while still preserving the global baseline unless the closer file explicitly tightens it.\\n"}'
+  '{"agents/evolution-planner/agent.toml":"name = \\"evolution-planner\\"\\ndescription = \\"Turn repeated writeback into concrete capability proposals.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou plan capability evolution.\\n\\nPrioritize:\\n- smallest useful change\\n- correct target asset type\\n- correct target scope\\n- evidence that justifies the change\\n- repeated writeback clusters or clearly missing capabilities, not isolated preferences\\n\\nProposal kinds you should consider first:\\n- update_asset\\n- create_asset\\n- extract_snippet\\n- add_skill\\n- promote_asset\\n\\nDefault to project scope when the pattern is repo-local.\\nPromote to global only when reuse is demonstrated and pollution risk is low.\\n\\nReturn concise proposals ordered by expected leverage, including:\\n- proposal kind\\n- target asset\\n- target scope\\n- why this is the smallest durable change\\n- source writeback ids or evidence summary\\n- approval risk and verification path\\n\\nDo not escalate to evolution when a single writeback is enough.\\nDo not use evolution as a substitute for executable task tracking when the main need is owner, priority, state, or implementation follow-through.\\nDo not globalize private, repo-specific, or speculative guidance.\\n\\"\\"\\"\\n","agents/integration-auditor/agent.toml":"name = \\"integration-auditor\\"\\ndescription = \\"Find where local success can still fail system-wide.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou audit integration risk.\\n\\nPrioritize:\\n- hidden dependencies\\n- rollout hazards\\n- operational constraints\\n- gaps between local verification and real system behavior\\n- packaged, installed, rendered, or synced paths that differ from source behavior\\n- parallel execution and state-location risks\\n- privacy boundaries between global, project, generated, and machine-local state\\n\\nReturn concise findings ordered by impact. For each finding include:\\n- boundary at risk\\n- why the current evidence is or is not enough\\n- strongest next verification step\\n- whether the fix belongs in code, docs, a task, or capability evolution\\n\\"\\"\\"\\n","agents/scope-promoter/agent.toml":"name = \\"scope-promoter\\"\\ndescription = \\"Decide whether learning belongs at project or global scope.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou decide scope.\\n\\nPrioritize:\\n- project specificity\\n- cross-project reuse potential\\n- pollution risk from globalizing too early\\n- private or repo-specific details that must not move into global capability\\n- whether a smaller snippet, instruction, skill, or agent should be promoted instead of a broad doc\\n\\nWhen recommending promotion, make the standard path explicit:\\n- keep the source capability in project scope until promotion is approved\\n- create a reviewable global proposal\\n- do not treat promotion as implicit apply\\n\\nReturn concise decisions with:\\n- recommended scope\\n- target asset or smallest unit\\n- evidence for reuse\\n- privacy/pollution risk\\n- promotion path or no-op rationale\\n\\"\\"\\"\\n","agents/writeback-curator/agent.toml":"name = \\"writeback-curator\\"\\ndescription = \\"Turn noisy outcomes into high-signal writeback.\\"\\n\\ndeveloper_instructions = \\"\\"\\"\\nYou curate durable writeback.\\n\\nPrioritize:\\n- repeated failures\\n- repeated wins\\n- stale guidance\\n- missing capability edges\\n- tool, skill, MCP, plugin, automation, or instruction friction that repeatedly slows work down\\n\\nFor each recommendation, prefer returning:\\n- suggested writeback kind\\n- best target asset or destination\\n- best scope (`project` or `global`)\\n- the evidence that justifies recording it\\n- whether the signal is enough for writeback only, task tracking, or evolution\\n\\nDo not emit low-signal noise.\\nIf the learning is repo-specific, keep it project-scoped by default.\\nWhen the signal is already strong and the target is clear, prefer recommending direct writeback capture rather than abstract advice.\\nWhen the issue is executable tooling work, recommend task tracking for the fix and writeback only for the reusable operating-model learning.\\nWhen the issue contains private project details, preserve the general learning without copying private details into a global asset.\\n\\"\\"\\"\\n","instructions/CAPABILITY_COMPOSITION.md":"---\\ndescription: \\"Compose small capability units across global and project roots, then evolve the smallest affected unit.\\"\\ntags: [\\"facult\\", \\"composition\\", \\"refs\\", \\"snippets\\", \\"instructions\\"]\\n---\\n\\n# Capability Composition\\n\\nUse `fclt` capability as small units that can be composed, inspected, rendered, and evolved independently.\\n\\nThe main units are:\\n\\n- instructions: standalone markdown doctrine such as language preferences, verification rules, or review standards\\n- snippets: small markdown partials inserted into one or more rendered docs\\n- skills: task-specific workflows with `SKILL.md`\\n- agents: focused role manifests\\n- MCP definitions: tool interfaces and their safe auth shape\\n- automations: scheduled review or maintenance loops\\n- tool rules/config: tool-specific defaults and policy\\n\\n## Composition Rules\\n\\n- Keep reusable doctrine in `instructions/`.\\n- Keep repeated paragraphs or policy blocks in `snippets/`.\\n- Keep workflow execution in `skills/`.\\n- Keep persona or delegation behavior in `agents/`.\\n- Keep tool wiring in `mcp/` and `tools/<tool>/`.\\n- Compose broad agent docs from refs and snippets instead of copying text by hand.\\n- Prefer one narrow reusable unit over one large instruction file that mixes unrelated domains.\\n\\nExamples:\\n\\n- `@ai/instructions/LANGUAGE.md` for a user-owned language/tooling preference.\\n- `@ai/instructions/REVIEW.md` for a user-owned review standard.\\n- `@project/instructions/TESTING.md` for repo-specific test policy.\\n- `<!-- fclty:global/codex/baseline -->` for a shared rendered block.\\n\\n## Scope\\n\\nUse global scope for capability that should follow the user across projects.\\n\\nUse project scope for capability that belongs to a repo, team workflow, architecture, or local test harness.\\n\\nPromote project capability to global only when repeated evidence shows reuse across projects. Do not globalize a project quirk just because it worked once.\\n\\n## Writeback and Evolution\\n\\nTarget the smallest affected unit.\\n\\n- If a paragraph is reused in several rendered docs, target the snippet.\\n- If a domain rule is wrong, target the instruction.\\n- If a workflow is incomplete, target the skill.\\n- If a delegated role is unclear, target the agent.\\n- If a tool interface is missing or unsafe, target the MCP or tool config.\\n- If a scheduled review loop is noisy or missing context, target the automation.\\n\\nGood writeback targets are graph-backed selectors when possible:\\n\\n```bash\\nfclt ai writeback add --kind missing_context --summary \\"Language guidance did not cover test runner selection.\\" --asset instruction:LANGUAGE\\nfclt ai writeback add --kind reusable_pattern --summary \\"Project test policy should become a shared verification snippet.\\" --asset @project/instructions/TESTING.md\\nfclt ai writeback add --kind bad_default --summary \\"The review automation escalated one-off preferences.\\" --asset automation:evolution-review\\n```\\n\\nUse `fclt ai evolve ...` only after repeated signal, a clearly missing capability, or a stale canonical asset points at a concrete change. Prefer the smallest valid proposal kind: `update_asset`, `create_asset`, `extract_snippet`, `add_skill`, or `promote_asset`.\\n\\n## Agent Defaults\\n\\nWhen an agent sees a repeated language, framework, or test preference, it should not bury that in chat. It should identify whether the durable unit is:\\n\\n- a global instruction\\n- a project instruction\\n- a snippet reused by rendered docs\\n- a skill workflow\\n- a project-to-global promotion candidate\\n\\nThen it should record writeback against that unit, or draft a proposal when the evidence is already strong enough.\\n","instructions/EVOLUTION.md":"---\\ndescription: Turn repeated signal into concrete capability changes.\\ntags: [facult, evolution, writeback]\\n---\\n\\n# Evolution\\n\\nUse writeback and evolution to improve the AI operating layer itself.\\n\\nEvolution is the synthesis and change side of the feedback loop. It turns accumulated writebacks, repeated tool friction, stale canonical assets, or clearly missing capability into small reviewable changes to instructions, skills, snippets, agents, or other markdown canonical assets.\\n\\nUse capability composition when choosing the target. Instructions, snippets, skills, agents, MCP/tool config, and automations are separate units. Target the smallest unit that actually needs to change instead of rewriting a broad agent doc.\\n\\n## When To Record Writeback\\n\\nRecord writeback when one of these is true:\\n\\n- the same failure repeats\\n- the same success pattern repeats\\n- guidance is stale or missing\\n- a prompt or loop has to be restated often\\n- a project-specific pattern looks reusable\\n\\nDo not record low-signal noise:\\n\\n- one-off annoyance with no reuse value\\n- generic \\"could be better\\" commentary\\n- duplicate observations with no new evidence\\n\\nThe intended default is that agents record strong writebacks themselves when the signal is clear enough, rather than only recommending that a user do it manually later.\\n\\nDo not wait for a weekly review to preserve high-signal evidence. Do wait for repeated evidence or a clearly missing capability before drafting a proposal.\\n\\n## Scope\\n\\nChoose `project` scope when the learning depends on:\\n\\n- repo architecture\\n- team workflow\\n- project tooling\\n- local testing or verification behavior\\n\\nChoose `global` scope when the learning is reusable across projects.\\n\\nPromote from project to global only after repeated reuse or strong evidence.\\n\\n## Writeback Kinds\\n\\nCommon kinds:\\n\\n- `weak_verification`\\n- `false_positive`\\n- `missing_context`\\n- `reusable_pattern`\\n- `capability_gap`\\n- `bad_default`\\n\\nEvery good writeback should try to include:\\n\\n- a concrete summary\\n- the best target asset if known\\n- the right scope\\n- domain or tags when useful\\n\\nGood target examples:\\n\\n- `instruction:LANGUAGE` when shared language/tooling guidance is stale or missing\\n- `@project/instructions/TESTING.md` when repo test policy needs project-scoped evolution\\n- `snippet:global/policy/review` when a repeated rendered block should be fixed or extracted\\n- `skill:capability-evolution` when a workflow skill is missing steps or examples\\n- `automation:evolution-review` when the scheduled review loop is noisy or incomplete\\n\\n## Operator Flow\\n\\nTypical workflow:\\n\\n```bash\\nfclt ai writeback add --kind weak_verification --summary \\"Checks were too shallow\\" --asset instruction:VERIFICATION\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve assess --asset instruction:VERIFICATION --json\\nfclt ai evolve propose\\nfclt ai evolve draft EV-00001\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\nUse `fclt ai evolve draft <id> --append \\"...\\"` to revise a draft while preserving draft history.\\n\\nReview surfaces:\\n\\n- open `~/.ai/writebacks/` and `~/.ai/evolution/` in a Markdown editor for frontmatter-rich global and project-scoped review artifacts\\n- `fclt status --json` for queue/proposal paths, review artifact paths, counts, and active scope\\n- `fclt ai writeback list|show|group|summarize` for raw and clustered signal\\n- `fclt ai evolve assess` for read-only proposal readiness and the safest next action\\n- `fclt ai evolve list|show|review` for proposal state without applying changes\\n- `fclt templates init automation learning-review` for recurring capture/review\\n- `fclt templates init automation evolution-review` for recurring proposal review\\n- `fclt templates init automation tool-call-audit` for repeated tool-friction review\\n\\nEvolution proposal metadata, markdown drafts, patch artifacts, writeback queues,\\nand journals are runtime state. `fclt` stores JSON queues, proposal records,\\ndraft refs, patches, and journals in machine-local `fclt` state. It mirrors\\nhuman-readable review artifacts into global `~/.ai/writebacks/...` and\\n`~/.ai/evolution/...`, including project-scoped artifacts under\\n`projects/<slug-hash>/` with cwd/project metadata in frontmatter. Canonical\\nassets in `~/.ai` or `<repo>/.ai` should only change when a proposal is applied.\\n\\n## Default Agent Behavior\\n\\nUse the smallest action that fits the signal:\\n\\n1. record one strong writeback when there is a clear durable learning\\n2. use `writeback-curator` when the target, kind, or scope is ambiguous\\n3. run `fclt ai evolve assess --asset <selector> --json` before proposing when a target is known\\n4. use `capability-evolution` or `evolution-planner` when repeated signal should become a proposal\\n5. do not draft or apply proposals just because a writeback exists; require repeated evidence or a clearly missing capability\\n\\nWhen assessment recommends no mutation or more writeback, agents should still produce a useful review: state the current target, evidence grade, missing signal, exact recurrence that would justify evolution, and any read-only follow-up. Do not end with only \\"no proposal\\".\\n\\nAvoid creating writeback/evolution noise for one-off nits, vague preferences, or speculative ideas without evidence.\\n\\nWhen the friction is executable product/tooling work that needs ownership,\\npriority, state, or implementation follow-through, create or update a real task\\nsystem item instead of forcing it into capability evolution. Use evolution for\\nthe reusable operating-layer change.\\n\\n## Proposal Kinds\\n\\nCurrent supported proposal kinds:\\n\\n- `update_asset`\\n- `create_asset`\\n- `extract_snippet`\\n- `add_skill`\\n- `promote_asset`\\n\\nUse the smallest durable change that fits the evidence.\\n\\nExamples:\\n\\n- `update_asset`: fix a stale instruction, snippet, agent, or automation markdown asset.\\n- `create_asset`: add a missing instruction such as `LANGUAGE.md` or `REVIEW.md`.\\n- `extract_snippet`: move repeated guidance out of several docs into one snippet.\\n- `add_skill`: create a workflow when instructions are not enough.\\n- `promote_asset`: move a proven project instruction/snippet/skill toward global reuse.\\n\\n## Review And Apply Rules\\n\\n- draft before apply\\n- accept before apply\\n- prefer the smallest safe change\\n- keep reviewable evidence tied to source writebacks\\n- do not globalize project behavior too early\\n- do not apply high-risk global instruction, skill, plugin, or shared-tool changes without explicit review/approval\\n\\nApply is for markdown canonical assets only. If the target is wrong, revise the proposal rather than forcing it through.\\n","instructions/INTEGRATION.md":"---\\ndescription: Detect where local success can still fail at integration boundaries.\\ntags: [facult, integration, verification]\\n---\\n\\n# Integration\\n\\nDistinguish local correctness from system correctness. Check hidden dependencies, rollout order, and operational constraints before calling work done.\\n\\n## When To Use\\n\\nUse this when a local green signal may still fail at a boundary:\\n\\n- code passes focused tests but has not been checked against the real workflow\\n- docs are correct in isolation but may send agents to a stale command or path\\n- a tool command works locally but may fail under packaged, sandboxed, or parallel execution\\n- a capability change renders into one agent tool but not another\\n- a project-local improvement may collide with global defaults or managed output\\n- a migration, release, or rollout has ordering constraints\\n\\n## Integration Questions\\n\\nAsk the smallest set that matches the risk:\\n\\n- What consumes this output?\\n- What state does this depend on?\\n- What happens if two agents or commands run this at the same time?\\n- Does the packaged/released path behave like the source checkout?\\n- Does the project-scoped path avoid leaking into global or public surfaces?\\n- Does the global path avoid overwriting tool-native or user-edited state?\\n- Is rollback or recovery clear if the integration fails?\\n\\n## Evidence\\n\\nPrefer evidence that crosses the boundary that could fail:\\n\\n- run the installed CLI, packaged binary, or generated artifact when source tests are not enough\\n- inspect rendered output when changing snippets, refs, or agent docs\\n- use temp roots and clean homes for setup, upgrade, and sync behavior\\n- verify review artifacts land in global `~/.ai/writebacks` or `~/.ai/evolution`, not repo-local private state\\n- check release, package, or plugin surfaces when the change affects users outside the repo\\n\\n## Output\\n\\nReturn concise findings ordered by risk:\\n\\n- boundary checked\\n- evidence used\\n- remaining assumption\\n- fix or follow-up if local correctness does not prove system correctness\\n\\nRecord writeback when the same integration boundary repeatedly fails, the verification loop is too weak, or a missing skill/tool would make the boundary easier to check next time.\\n","instructions/LEARNING_AND_WRITEBACK.md":"---\\ndescription: Preserve durable signal and record writeback when the operating layer should learn.\\ntags: [facult, learning, writeback]\\n---\\n\\n# Learning And Writeback\\n\\nUse this when work produces a durable decision, failure, success pattern, or missing guardrail that should outlive the current task.\\n\\nThis is the capture side of the feedback loop. The goal is to let normal agent work produce reusable signal without requiring a human to manually restate every friction point later.\\n\\n## Default Behavior\\n\\nThe normal path should be agent-driven.\\n\\nIf you can clearly answer:\\n\\n- what was learned\\n- why it matters\\n- where it should land\\n- whether it belongs in `project` or `global`\\n\\nthen record the writeback instead of only suggesting that someone should do it later.\\n\\nUse:\\n\\n```bash\\nfclt ai writeback add --kind <kind> --summary \\"<summary>\\" --asset <asset-selector>\\n```\\n\\nThe writeback queue is runtime state, not canonical source. `fclt` stores JSON\\nqueue state in machine-local `fclt` state so sandboxed agents can record durable\\nfriction without mutating canonical assets unless an evolution proposal is later\\nreviewed and applied.\\n\\nEvery writeback also refreshes a Markdown review artifact under the global\\n`~/.ai/writebacks/...` tree. Global signal lands in `~/.ai/writebacks/global/`;\\nproject-scoped signal lands in `~/.ai/writebacks/projects/<slug-hash>/` with\\nfrontmatter for scope, project root, cwd, target asset, status, tags, evidence,\\nand timestamps. Do not write writeback review artifacts into a repo-local `.ai`;\\nrepo-local state should contribute project metadata and evidence, not bundled\\nprivate review files.\\n\\nProject-scoped writebacks should usually be recorded from the repo that produced\\nthe evidence. Global writebacks should be reserved for shared doctrine, shared\\nskills, shared agents, tool behavior, or cross-project capability gaps.\\n\\nTarget the smallest composable unit that explains the friction:\\n\\n- instruction: domain guidance, preferences, verification rules, or review doctrine\\n- snippet: repeated markdown block used by more than one rendered doc\\n- skill: workflow execution steps or examples\\n- agent: delegated role behavior\\n- MCP/tool config: tool interface, auth shape, or rendered integration\\n- automation: scheduled review loop, cadence, prompt, or memory\\n\\n## Record Writeback When\\n\\n- the same failure or weak loop appears again\\n- a reusable success pattern shows up\\n- guidance is clearly stale or missing\\n- a repo-local behavior probably belongs in project capability\\n- a cross-project behavior probably belongs in global capability\\n- a skill, tool, MCP, plugin, automation, or instruction gap repeatedly slows work down\\n- an agent has to restate the same workaround, verification rule, or review rule\\n- a repeated preference should become an atomic user-owned instruction or project-specific testing policy\\n\\n## Do Not Record Writeback For\\n\\n- one-off annoyance with no durable value\\n- weak commentary with no target\\n- speculative ideas without evidence\\n- duplicate noise with no new signal\\n\\n## Follow Through\\n\\n- prefer one strong writeback over many weak ones\\n- mention the writeback id when summarizing what changed\\n- escalate to `capability-evolution` or `fclt ai evolve ...` only when the signal is repeated or clearly points at a durable capability change\\n- use `fclt ai writeback group --by asset` or `fclt ai writeback summarize --by domain` to review accumulated signal before proposing broad changes\\n- use scheduled `learning-review`, `evolution-review`, or `tool-call-audit` automations when the signal should be reviewed in the background\\n","instructions/PROJECT_CAPABILITY.md":"---\\ndescription: Decide what belongs in repo-local .ai versus the global store.\\ntags: [facult, project, scope]\\n---\\n\\n# Project Capability\\n\\nPrefer project scope when the guidance depends on repo architecture, team workflow, or colocated tooling. Promote to global only after repeated cross-project reuse.\\n\\n## Project First\\n\\nDefault to `<repo>/.ai` when the capability is about:\\n\\n- local architecture\\n- repo-specific testing or verification\\n- team conventions\\n- project tools and workflows\\n- product, customer, deployment, or operational context tied to one repo\\n- examples that would leak private or irrelevant detail if copied globally\\n\\nProject capability should travel with the repo when it is safe to commit. Generated state, machine-local runtime state, secrets, and review queues should not travel with it.\\n\\n## Global Scope\\n\\nUse `~/.ai` when the capability should follow the user across projects:\\n\\n- general verification standards\\n- reusable work-unit, feedback-loop, or writeback doctrine\\n- user-owned language/tool preferences that are safe to share across repos\\n- cross-project skills or agents\\n- MCP/tool integration patterns that are not tied to one repo\\n\\nGlobal capability should be broadly useful and low-noise. A global rule that only helps one project is usually a project rule.\\n\\n## Review Artifacts\\n\\nProject-scoped writebacks and evolution proposals use the project as evidence, but their Markdown review artifacts are mirrored under global `~/.ai/writebacks/projects/<slug-hash>/` and `~/.ai/evolution/projects/<slug-hash>/`.\\n\\nDo not create repo-local `writebacks/` or `evolution/` review trees inside `<repo>/.ai`. Keep private review state out of the repo while preserving project metadata in the global review artifact frontmatter.\\n\\n## Promote Carefully\\n\\nPromote to `~/.ai` only when:\\n\\n- the same pattern succeeds in more than one repo\\n- the capability is not coupled to local architecture\\n- the global version will not create noise for unrelated projects\\n- private examples can be removed or generalized without losing the rule\\n- the target global unit is smaller than a broad rewrite\\n\\nUse:\\n\\n```bash\\nfclt ai evolve promote EV-00001 --to global --project\\n```\\n\\nThat creates a new global proposal for review. It does not auto-apply the promotion.\\n\\n## Decision Checklist\\n\\nChoose project when the answer depends on \\"this repo\\". Choose global when the answer would still be correct after removing the repo name.\\n\\nIf unsure:\\n\\n1. keep the asset project-scoped\\n2. record writeback with the reason it might generalize\\n3. wait for another project or repeated evidence\\n4. promote through a reviewable proposal, not by copying files by hand\\n","instructions/WORK_UNITS.md":"---\\ndescription: \\"Define work units so agent tasks have a clear goal, evidence path, artifact, and writeback target.\\"\\ntags: [\\"work-units\\", \\"planning\\", \\"verification\\", \\"writeback\\"]\\n---\\n\\n# Work Units\\n\\nA work unit is the smallest coherent unit of agent work that can be understood, verified, and preserved.\\n\\nIt is not just the user\'s latest sentence. It is the operational shape around that sentence: what is being changed, why it matters, what evidence is needed, what artifact should remain, and how future agents should benefit from the result.\\n\\nUse work units for ordinary work, not only for capability updates. Coding changes, research answers, documentation edits, operational triage, setup repair, design reviews, and capability evolution all benefit from the same shape when the task has real uncertainty or risk.\\n\\n## Minimum Contract\\n\\nA well-formed work unit names:\\n\\n- goal: the outcome the user needs\\n- acceptance criteria: what must be true when the work is done\\n- required context: source files, docs, systems, messages, or prior decisions needed for correctness\\n- constraints: permissions, privacy, compatibility, deadlines, ownership, or scope limits\\n- signals or evidence: checks that can confirm progress or falsify assumptions\\n- output artifact: code, docs, proposal, issue, note, draft, or report\\n- verification path: commands, review surfaces, manual checks, or source-of-truth reads\\n- writeback target: where durable learning belongs if the work teaches something reusable\\n\\nIf one of these is missing and the gap blocks correctness, surface the gap early and recover it before moving faster.\\n\\nFor low-risk one-step work, keep the contract implicit. For ambiguous, high-impact, cross-tool, stateful, or multi-step work, make the contract explicit before executing.\\n\\n## Why It Exists\\n\\nWork-unit framing prevents shallow completion. It helps agents avoid:\\n\\n- changing files before understanding the target\\n- treating a weak green signal as proof\\n- losing reusable learning in chat\\n- creating duplicate tasks or proposals\\n- turning one-off preferences into global rules\\n- pushing project-specific details into global capability\\n- producing output faster than the system can review, integrate, or learn from it\\n\\nThe point is not paperwork. The point is to attach machine work to intent, context, evidence, and memory so that useful learning can change future work instead of disappearing into chat history.\\n\\n## How To Use It\\n\\nFor simple tasks, keep the work unit implicit but still verify the result.\\n\\nFor ambiguous, high-impact, or multi-step tasks, make the work unit explicit before executing. A compact form is enough:\\n\\n```text\\nGoal:\\nAcceptance:\\nContext:\\nConstraints:\\nEvidence:\\nArtifact:\\nVerification:\\nWriteback:\\n```\\n\\nUse the smallest framing that makes the task correct. Do not turn every request into paperwork.\\n\\n## Examples\\n\\nCoding:\\n\\n```text\\nGoal: fix the failing login test\\nAcceptance: test passes and no auth regression is introduced\\nContext: failing test output, auth middleware, recent commits\\nConstraints: preserve public API\\nEvidence: focused test, relevant integration test\\nArtifact: code diff and concise summary\\nVerification: command output and changed behavior\\nWriteback: only if the failure exposes stale test or auth guidance\\n```\\n\\nResearch:\\n\\n```text\\nGoal: answer a source-backed product question\\nAcceptance: answer cites current primary sources\\nContext: user question, relevant docs, dates\\nConstraints: distinguish verified facts from inference\\nEvidence: source links and quotes within fair-use limits\\nArtifact: answer or research note\\nVerification: source freshness and consistency check\\nWriteback: durable note if the finding will recur\\n```\\n\\nCapability evolution:\\n\\n```text\\nGoal: decide whether repeated writebacks justify a proposal\\nAcceptance: proposal exists only if evidence repeats or a capability is clearly missing\\nContext: grouped writebacks, target asset, current canonical guidance\\nConstraints: avoid global noise and private leakage\\nEvidence: writeback IDs and affected work units\\nArtifact: accepted proposal, rejected proposal, or no-op note\\nVerification: proposal kind, scope, target, and review artifact\\nWriteback: only for new meta-learning about the evolution process\\n```\\n\\n## Writeback\\n\\nWhen the work reveals durable friction, missing capability, stale guidance, or a repeatable workflow, prefer one strong writeback over many weak ones.\\n\\nUse `fclt ai writeback add ...` when the target asset, scope, and evidence are clear. Use `fclt ai evolve ...` only when repeated signal supports a concrete proposal.\\n","skills/capability-evolution/SKILL.md":"---\\ndescription: Convert repeated writeback into concrete fclt capability proposals.\\ntags: [facult, evolution, writeback]\\n---\\n\\n# capability-evolution\\n\\n## When To Use\\nUse this skill when the same missing guidance, weak loop, or recurring win appears often enough that the AI system itself should probably change.\\n\\nDo not wait for a human operator by default if the signal is already clear and the environment permits local AI runtime state to be updated.\\n\\nUse writeback first when the signal is useful but not yet repeated. Use evolution when accumulated writebacks, repeated tool friction, or a clearly missing capability point at a specific target asset or new capability.\\n\\nThe goal is a governed feedback loop: work creates evidence, evidence produces writeback, repeated writeback becomes a small reviewed proposal, and accepted proposals change future agent behavior.\\n\\n## Scope Decision\\n\\nChoose `project` when the behavior depends on repo-local architecture or workflow.\\n\\nChoose `global` when the behavior is broadly reusable.\\n\\nIf unsure, start at project scope and promote later with evidence.\\n\\nReject global scope when the proposal depends on private examples, one repo\'s architecture, a single user\'s temporary preference, or a workflow that has not repeated.\\n\\n## Working Flow\\n\\n1. Read current writebacks and existing proposals.\\n2. Group or summarize repeated signal by asset, kind, and scope.\\n3. Run a read-only evolution assessment for the target when possible.\\n4. Check the current target asset before proposing a change.\\n5. Choose the smallest valid proposal kind.\\n6. Draft the proposal with evidence and intended target.\\n7. Accept only after the target and scope are correct.\\n8. Apply only when the markdown target is the intended canonical asset.\\n\\nUse:\\n\\n```bash\\nfclt ai writeback add ...\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve assess --asset <selector> --json\\nfclt ai evolve propose\\nfclt ai evolve draft EV-00001\\nfclt ai evolve draft EV-00001 --append \\"tighten the rule with a concrete verification step\\"\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\nFor background review loops, use:\\n\\n```bash\\nfclt templates init automation learning-review\\nfclt templates init automation evolution-review\\nfclt templates init automation tool-call-audit\\n```\\n\\nIf there is not yet enough repeated signal for evolution, do not stop at a bare \\"no\\". Explain what evidence would change the decision, whether another writeback should be recorded, and the smallest future target if the pattern repeats.\\n\\nDo not create a proposal only to preserve an idea. Preserve the idea as writeback, notes, or task tracking unless it has enough evidence to change capability.\\n\\n## Proposal Kind Selection\\n\\n- `update_asset` for tightening existing guidance\\n- `create_asset` for missing instructions or docs\\n- `extract_snippet` for reusable partial guidance\\n- `add_skill` for reusable workflow instruction\\n- `promote_asset` for project-to-global promotion\\n\\nUse task tracking instead of evolution when the main work is an executable tool or product fix that needs an owner, priority, state, or delivery plan. Use evolution for the reusable instruction, skill, or operating-model change that should survive that fix.\\n\\n## Review Criteria\\n\\nBefore accept/apply, verify:\\n\\n- evidence is repeated or the missing capability is obvious\\n- the proposal targets the smallest affected unit\\n- project/global scope is correct\\n- private or project-specific examples are not leaking into global assets\\n- the patch changes canonical markdown assets, not generated runtime state\\n- the resulting behavior can be verified by reading, rendering, indexing, or running the relevant command\\n\\n## Output Contract\\n- repeated signal\\n- proposed asset change\\n- target scope\\n- evidence\\n- smallest useful next step\\n- approval or no-op rationale\\n- next evidence to collect when no proposal is justified\\n- exact read-only and mutating commands, with approval boundaries\\n","skills/project-operating-layer-design/SKILL.md":"---\\ndescription: Design or improve a repo-local .ai operating layer.\\ntags: [facult, project, design]\\n---\\n\\n# project-operating-layer-design\\n\\n## When To Use\\nUse this skill when a project needs its own `.ai/` structure, repo-specific instructions, or local bootstrap guidance.\\n\\nUse it when:\\n\\n- a repo has recurring agent friction that should not become global doctrine\\n- setup or verification steps are repeatedly rediscovered\\n- project skills, agents, MCP definitions, or snippets need a stable source of truth\\n- a repo needs policy for what may be rendered into tool homes\\n- a project should contribute writeback/evolution evidence without committing private review artifacts\\n\\nDo not use it to copy a user\'s private global preferences into a public repo.\\n\\n## Design Rules\\n\\n- Start from the repo\'s real workflows, commands, and risk boundaries.\\n- Keep project-specific guidance in `<repo>/.ai`.\\n- Keep generated state, queues, review artifacts, and local machine config out of the repo.\\n- Prefer a few high-leverage instructions or skills over a large generic dump.\\n- Use snippets only for blocks that are reused or independently evolvable.\\n- Make verification and integration paths explicit enough for future agents to run.\\n- Add sync policy only for assets that should render into repo-local tool outputs.\\n\\n## Working Flow\\n\\n1. Inventory existing repo guidance and tool files.\\n2. Identify repeated friction from recent work, issues, reviews, or writebacks.\\n3. Separate project-specific behavior from global/user-owned behavior.\\n4. Propose a minimal `.ai` layout.\\n5. Add or update the smallest useful assets.\\n6. Verify the graph/index and any rendered output.\\n7. Record writeback for reusable learnings that should evolve later.\\n\\n## Output Contract\\n- recommended `.ai/` layout\\n- what stays project-local\\n- what stays global\\n- what should remain generated runtime output only\\n- sync/rendering policy\\n- verification path\\n- privacy or commit-safety risks\\n","snippets/global/baseline.md":"- Preserve existing user changes unless asked to rewrite them.\\n- Prefer small, reviewable diffs and verify meaningful changes before claiming success.\\n- State constraints, risks, and follow-up steps directly.\\n","snippets/global/core/feedback-loops.md":"- For any task, identify the highest-signal feedback loops available.\\n- Prefer loops that can verify progress, falsify weak assumptions, and expose failure early.\\n- Do not rely on a single shallow positive signal if stronger verification exists.\\n- If the available loop is stale, weak, noisy, or easy to game, improve it or say what is missing.\\n- When useful, leave behind a stronger loop than the one you started with.\\n- Treat verification, evaluation, and writeback as part of the work, not cleanup after it.\\n- For work-unit clarification, read ${refs.work_units}.\\n- For verification guidance, read ${refs.verification}.\\n- For integration risk, read ${refs.integration}.\\n- For learning and writeback, read ${refs.learning_writeback}.\\n- For deeper guidance, read ${refs.feedback_loops}.\\n","snippets/global/core/verification.md":"- Treat verification as part of the work, not a final checkbox.\\n- Prefer the strongest available proof that matches the real risk.\\n- Make clear what has actually been verified and what remains assumed.\\n- Distrust shallow green signals when stronger checks are available.\\n- If the current harness is stale, weak, or misleading, say so and improve it where possible.\\n- For deeper guidance, read ${refs.verification}.\\n","snippets/global/core/work-units.md":"- Treat every task as a work unit, not just a request.\\n- A work unit should have a goal, acceptance criteria, required context, constraints, signals or evidence, an output artifact, a verification path, and a writeback target when the work teaches something reusable.\\n- If any of those are missing and the gap blocks correctness, surface it early and try to recover it.\\n- Prefer making the work unit more explicit before increasing execution speed.\\n- If the task is vague, ambiguous, or overloaded, narrow it before acting.\\n- Treat work-unit framing as generally applicable to coding, research, writing, operations, setup, debugging, and capability evolution.\\n- For deeper guidance, read ${refs.work_units}.\\n","snippets/global/core/writeback.md":"- Do not end at output if something important was learned.\\n- Preserve decisions, failures, successes, and reusable signal when they will improve future work.\\n- Prefer writing to a real destination over leaving knowledge in chat.\\n- When useful, leave behind better docs, tests, evals, prompts, notes, or follow-up tasks.\\n- When a high-signal learning clearly points at a canonical asset or durable destination, record a writeback before ending the task.\\n- Prefer one strong writeback over many weak ones.\\n- If you can name the target asset, the expected scope, and the actual signal, use `fclt ai writeback add ...` instead of merely mentioning that writeback would be useful.\\n- If repeated signal is already accumulating, use the `capability-evolution` skill or `fclt ai evolve ...` flow to turn it into a reviewable proposal.\\n- For deeper guidance, read ${refs.learning_writeback}.\\n","snippets/templates/agents-global.md":"# Global Agent Instructions\\n\\nThis template materializes as `AGENTS.global.md` when the operating-model pack is\\ninstalled. It should stay small and composed from snippets. Put detailed\\ndoctrine in instructions, workflow execution in skills, and local/private\\npreferences in user-owned or project-owned assets outside the public pack.\\n\\n## Working mode\\n\\n<!-- fclty:global/baseline -->\\n<!-- /fclty:global/baseline -->\\n\\n<!-- fclty:global/core/work-units -->\\n<!-- /fclty:global/core/work-units -->\\n\\n<!-- fclty:global/core/feedback-loops -->\\n<!-- /fclty:global/core/feedback-loops -->\\n\\n<!-- fclty:global/core/verification -->\\n<!-- /fclty:global/core/verification -->\\n\\n<!-- fclty:global/core/writeback -->\\n<!-- /fclty:global/core/writeback -->\\n\\n## Shared instruction sources\\n\\n- For work-unit definition and scope clarification, read ${refs.work_units}.\\n- For identifying, improving, and validating feedback loops, read ${refs.feedback_loops}.\\n- For verification and anti-false-positive checks, read ${refs.verification}.\\n- For checking integration boundaries, read ${refs.integration}.\\n- For learning, decisions, and writeback, read ${refs.learning_writeback}.\\n- For capability evolution, proposal kinds, and `facult ai` workflow, read ${refs.evolution}.\\n- For deciding whether something belongs in global or project scope, read ${refs.project_capability}.\\n- Add private language, coding, or writing refs in local config only when they belong to the user\'s own operating layer.\\n\\n## Layering\\n\\n- Treat this file as the global baseline.\\n- Treat repo-level `AGENTS.md` files as more specific additions layered after this file.\\n- Repo-level files may add or refine project-specific behavior, but they should not weaken global defaults for rigor, verification, or writeback discipline.\\n- If a closer `AGENTS.override.md` exists, follow it as the most specific instructions file in that directory while still preserving the global baseline unless the closer file explicitly tightens it.\\n"}'
 ) as Record<string, string>;
 
 export const BUILTIN_FCLT_CODEX_PLUGIN_FILES = JSON.parse(
   // biome-ignore lint/suspicious/noTemplateCurlyInString: Built-in plugin files intentionally contain literal render placeholders.
-  '{".codex-plugin/plugin.json":"{\\n  \\"name\\": \\"fclt\\",\\n  \\"version\\": \\"0.1.0\\",\\n  \\"description\\": \\"Codex workflows and MCP tools for fclt setup, writeback, evolution, and capability review.\\",\\n  \\"license\\": \\"MIT\\",\\n  \\"keywords\\": [\\n    \\"fclt\\",\\n    \\"facult\\",\\n    \\"codex\\",\\n    \\"skills\\",\\n    \\"mcp\\",\\n    \\"writeback\\",\\n    \\"evolution\\"\\n  ],\\n  \\"skills\\": \\"./skills/\\",\\n  \\"mcpServers\\": \\"./.mcp.json\\",\\n  \\"interface\\": {\\n    \\"displayName\\": \\"fclt\\",\\n    \\"shortDescription\\": \\"Capability loops for Codex\\",\\n    \\"longDescription\\": \\"Install and operate fclt from Codex: initialize AI capability roots, inspect setup health, record writebacks, review evolution proposals, and keep skills, snippets, instructions, automations, and MCP surfaces improving over time.\\",\\n    \\"developerName\\": \\"Hack Dance\\",\\n    \\"category\\": \\"Productivity\\",\\n    \\"capabilities\\": [\\"Read\\", \\"Write\\", \\"MCP\\"],\\n    \\"defaultPrompt\\": [\\n      \\"Use fclt to check this repo\'s AI capability setup.\\",\\n      \\"Record useful fclt writeback from this work.\\",\\n      \\"Review fclt evolution proposals and next actions.\\"\\n    ],\\n    \\"brandColor\\": \\"#166534\\"\\n  }\\n}\\n",".mcp.json":"{\\n  \\"mcpServers\\": {\\n    \\"fclt\\": {\\n      \\"command\\": \\"node\\",\\n      \\"args\\": [\\"./scripts/fclt-mcp.cjs\\"],\\n      \\"env\\": {\\n        \\"FCLT_BIN\\": \\"fclt\\"\\n      }\\n    }\\n  }\\n}\\n","scripts/fclt-mcp.cjs":"#!/usr/bin/env node\\n\\"use strict\\";\\n\\nconst { spawn } = require(\\"node:child_process\\");\\n\\nconst FCLT_BIN = process.env.FCLT_BIN || \\"fclt\\";\\nconst DEFAULT_TIMEOUT_MS = Number(process.env.FCLT_MCP_TIMEOUT_MS || 60_000);\\nconst CONTENT_LENGTH_RE = /Content-Length:\\\\s*(\\\\d+)/i;\\n\\nconst tools = [\\n  {\\n    name: \\"fclt_status\\",\\n    description:\\n      \\"Return fclt status for the current, global, or project scope.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_doctor\\",\\n    description: \\"Run read-only fclt doctor checks and return JSON output.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_paths\\",\\n    description: \\"Return canonical, generated, review, and runtime fclt paths.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_init_operating_model\\",\\n    description: \\"Install or update the built-in operating-model pack.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        update: { type: \\"boolean\\" },\\n        dryRun: { type: \\"boolean\\" },\\n        force: { type: \\"boolean\\" },\\n      },\\n      required: [\\"scope\\"],\\n    },\\n  },\\n  {\\n    name: \\"fclt_writeback_add\\",\\n    description: \\"Record a durable fclt writeback with evidence.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        kind: { type: \\"string\\" },\\n        summary: { type: \\"string\\" },\\n        asset: { type: \\"string\\" },\\n        evidence: { type: \\"string\\" },\\n        confidence: {\\n          type: \\"string\\",\\n          enum: [\\"low\\", \\"medium\\", \\"high\\"],\\n        },\\n      },\\n      required: [\\"kind\\", \\"summary\\"],\\n    },\\n  },\\n  {\\n    name: \\"fclt_writeback_review\\",\\n    description: \\"List, group, or summarize current fclt writebacks.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        mode: { type: \\"string\\", enum: [\\"list\\", \\"group\\", \\"summarize\\"] },\\n        by: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_evolve\\",\\n    description: \\"List, propose, draft, or review fclt evolution proposals.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        action: {\\n          type: \\"string\\",\\n          enum: [\\"list\\", \\"propose\\", \\"draft\\", \\"review\\", \\"show\\"],\\n        },\\n        id: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n];\\n\\nfunction scopeArgs(scope) {\\n  if (scope === \\"global\\") {\\n    return [\\"--global\\"];\\n  }\\n  if (scope === \\"project\\") {\\n    return [\\"--project\\"];\\n  }\\n  return [];\\n}\\n\\nfunction boolFlag(name, value) {\\n  return value ? [name] : [];\\n}\\n\\nfunction stringFlag(name, value) {\\n  return typeof value === \\"string\\" && value.trim() ? [name, value] : [];\\n}\\n\\nfunction commandForTool(name, args = {}) {\\n  switch (name) {\\n    case \\"fclt_status\\":\\n      return [\\"status\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_doctor\\":\\n      return [\\"doctor\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_paths\\":\\n      return [\\"paths\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_init_operating_model\\":\\n      return [\\n        \\"templates\\",\\n        \\"init\\",\\n        \\"operating-model\\",\\n        ...scopeArgs(args.scope),\\n        ...boolFlag(\\"--update\\", args.update),\\n        ...boolFlag(\\"--dry-run\\", args.dryRun),\\n        ...boolFlag(\\"--force\\", args.force),\\n        \\"--json\\",\\n      ];\\n    case \\"fclt_writeback_add\\":\\n      return [\\n        \\"ai\\",\\n        \\"writeback\\",\\n        ...scopeArgs(args.scope),\\n        \\"add\\",\\n        \\"--kind\\",\\n        args.kind,\\n        \\"--summary\\",\\n        args.summary,\\n        ...stringFlag(\\"--asset\\", args.asset),\\n        ...stringFlag(\\"--evidence\\", args.evidence),\\n        ...stringFlag(\\"--confidence\\", args.confidence),\\n      ];\\n    case \\"fclt_writeback_review\\": {\\n      const mode = args.mode || \\"list\\";\\n      return [\\n        \\"ai\\",\\n        \\"writeback\\",\\n        ...scopeArgs(args.scope),\\n        mode,\\n        ...stringFlag(\\"--by\\", args.by),\\n      ];\\n    }\\n    case \\"fclt_evolve\\": {\\n      const action = args.action || \\"list\\";\\n      return [\\n        \\"ai\\",\\n        \\"evolve\\",\\n        ...scopeArgs(args.scope),\\n        action,\\n        ...(args.id ? [args.id] : []),\\n      ];\\n    }\\n    default:\\n      throw new Error(`Unknown tool: ${name}`);\\n  }\\n}\\n\\nfunction runFclt(args, cwd) {\\n  return new Promise((resolve) => {\\n    const child = spawn(FCLT_BIN, args, {\\n      cwd: cwd || process.cwd(),\\n      env: process.env,\\n      stdio: [\\"ignore\\", \\"pipe\\", \\"pipe\\"],\\n    });\\n    let stdout = \\"\\";\\n    let stderr = \\"\\";\\n    const timer = setTimeout(() => {\\n      child.kill(\\"SIGTERM\\");\\n    }, DEFAULT_TIMEOUT_MS);\\n    child.stdout.on(\\"data\\", (chunk) => {\\n      stdout += chunk.toString();\\n    });\\n    child.stderr.on(\\"data\\", (chunk) => {\\n      stderr += chunk.toString();\\n    });\\n    child.on(\\"close\\", (code) => {\\n      clearTimeout(timer);\\n      resolve({\\n        code,\\n        text: [\\n          `$ ${FCLT_BIN} ${args.join(\\" \\")}`,\\n          stdout.trim(),\\n          stderr.trim() ? `stderr:\\\\n${stderr.trim()}` : \\"\\",\\n        ]\\n          .filter(Boolean)\\n          .join(\\"\\\\n\\\\n\\"),\\n      });\\n    });\\n  });\\n}\\n\\nfunction send(message) {\\n  const body = JSON.stringify(message);\\n  process.stdout.write(\\n    `Content-Length: ${Buffer.byteLength(body)}\\\\r\\\\n\\\\r\\\\n${body}`\\n  );\\n}\\n\\nasync function handle(message) {\\n  if (!message || message.id == null) {\\n    return;\\n  }\\n\\n  try {\\n    if (message.method === \\"initialize\\") {\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: message.id,\\n        result: {\\n          protocolVersion: \\"2025-06-18\\",\\n          capabilities: { tools: {} },\\n          serverInfo: { name: \\"fclt\\", version: \\"0.1.0\\" },\\n        },\\n      });\\n      return;\\n    }\\n    if (message.method === \\"tools/list\\") {\\n      send({ jsonrpc: \\"2.0\\", id: message.id, result: { tools } });\\n      return;\\n    }\\n    if (message.method === \\"tools/call\\") {\\n      const { name, arguments: args = {} } = message.params || {};\\n      const command = commandForTool(name, args);\\n      const result = await runFclt(command, args.cwd);\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: message.id,\\n        result: {\\n          isError: result.code !== 0,\\n          content: [{ type: \\"text\\", text: result.text }],\\n        },\\n      });\\n      return;\\n    }\\n    send({\\n      jsonrpc: \\"2.0\\",\\n      id: message.id,\\n      error: { code: -32_601, message: `Method not found: ${message.method}` },\\n    });\\n  } catch (error) {\\n    send({\\n      jsonrpc: \\"2.0\\",\\n      id: message.id,\\n      error: {\\n        code: -32_000,\\n        message: error instanceof Error ? error.message : String(error),\\n      },\\n    });\\n  }\\n}\\n\\nlet buffer = Buffer.alloc(0);\\n\\nprocess.stdin.on(\\"data\\", (chunk) => {\\n  buffer = Buffer.concat([buffer, chunk]);\\n  while (true) {\\n    const headerEnd = buffer.indexOf(\\"\\\\r\\\\n\\\\r\\\\n\\");\\n    if (headerEnd === -1) {\\n      return;\\n    }\\n    const header = buffer.slice(0, headerEnd).toString(\\"utf8\\");\\n    const match = CONTENT_LENGTH_RE.exec(header);\\n    if (!match) {\\n      buffer = Buffer.alloc(0);\\n      return;\\n    }\\n    const length = Number(match[1]);\\n    const frameEnd = headerEnd + 4 + length;\\n    if (buffer.length < frameEnd) {\\n      return;\\n    }\\n    const body = buffer.slice(headerEnd + 4, frameEnd).toString(\\"utf8\\");\\n    buffer = buffer.slice(frameEnd);\\n    handle(JSON.parse(body)).catch((error) => {\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: null,\\n        error: {\\n          code: -32_000,\\n          message: error instanceof Error ? error.message : String(error),\\n        },\\n      });\\n    });\\n  }\\n});\\n\\nif (process.argv.includes(\\"--self-test\\")) {\\n  console.log(\\n    JSON.stringify({ tools: tools.map((tool) => tool.name) }, null, 2)\\n  );\\n  process.exit(0);\\n}\\n","skills/fclt-capability-review/SKILL.md":"---\\ndescription: Inspect fclt capability roots, docs, snippets, skills, agents, MCP, and automations.\\ntags: [fclt, capability, review, inventory]\\n---\\n\\n# fclt-capability-review\\n\\n## When To Use\\nUse this skill when Codex needs to understand what capability exists before changing it.\\n\\nUse it for:\\n\\n- checking global and project `.ai` roots\\n- finding relevant skills, snippets, instructions, agents, MCP servers, or automations\\n- deciding whether a change belongs in global or project scope\\n- checking whether managed rendering is enabled or needed\\n- reviewing public/private boundaries before publishing docs or pack assets\\n\\n## Workflow\\n\\n```bash\\nfclt status --json\\nfclt inventory --json\\nfclt list skills\\nfclt list instructions\\nfclt list snippets\\nfclt graph AGENTS.global.md\\n```\\n\\nFor project work:\\n\\n```bash\\nfclt status --project --json\\nfclt inventory --project --json\\n```\\n\\n## Rules\\n\\n- Read existing repo guidance before proposing project capability.\\n- Use project scope for repo-specific commands, tests, architecture, or team workflow.\\n- Use global scope only for broadly reusable behavior.\\n- Keep generated state and review artifacts out of repo-local `.ai`.\\n- Prefer adding or updating the smallest unit: instruction, snippet, skill, agent, MCP config, or automation.\\n\\n## Output\\n\\n- capability roots found\\n- relevant assets\\n- scope recommendation\\n- missing or stale capability\\n- safe next command\\n","skills/fclt-evolution/SKILL.md":"---\\ndescription: Turn repeated fclt writebacks into reviewed capability changes.\\ntags: [fclt, evolution, proposals, capability]\\n---\\n\\n# fclt-evolution\\n\\n## When To Use\\nUse this skill when repeated writebacks, stale canonical assets, or a clearly missing capability should become a concrete proposal.\\n\\nDo not use it for a single weak preference or speculative idea.\\n\\n## Workflow\\n\\n1. Review signal:\\n\\n```bash\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve list\\n```\\n\\n2. Propose only when evidence is strong enough:\\n\\n```bash\\nfclt ai evolve propose\\n```\\n\\n3. Draft and inspect:\\n\\n```bash\\nfclt ai evolve draft EV-00001\\nfclt ai evolve review EV-00001\\n```\\n\\n4. Accept/apply only when scope, target, and evidence are correct:\\n\\n```bash\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\n## Proposal Kinds\\n\\n- `update_asset`\\n- `create_asset`\\n- `extract_snippet`\\n- `add_skill`\\n- `promote_asset`\\n\\n## Rules\\n\\n- Prefer the smallest valid proposal kind.\\n- Keep project-specific behavior project-scoped until reuse is proven.\\n- Ask for approval before applying global instructions, global skills, plugin behavior, or other broad shared surfaces.\\n- Reject or park proposals that are stale, duplicated, vague, or unsupported.\\n- Use Linear or another task system for executable implementation work that needs owner, priority, or state.\\n\\n## Output\\n\\n- proposals reviewed\\n- repeated signal\\n- proposal created or updated\\n- approvals needed\\n- apply/reject/no-op rationale\\n","skills/fclt-setup/SKILL.md":"---\\ndescription: Install, update, inspect, and initialize fclt from Codex.\\ntags: [fclt, setup, codex, onboarding]\\n---\\n\\n# fclt-setup\\n\\n## When To Use\\nUse this skill when a user wants Codex to install, update, configure, inspect, or repair fclt.\\n\\nUse it for:\\n\\n- checking whether `fclt` is installed and current\\n- initializing global `~/.ai` or project `<repo>/.ai`\\n- installing or refreshing the built-in operating-model pack\\n- checking setup health with `doctor`\\n- finding canonical, generated, runtime, and review paths\\n\\n## Workflow\\n\\n1. Check current state:\\n\\n```bash\\nfclt --version\\nfclt paths --json\\nfclt doctor --json\\n```\\n\\n2. If global capability is missing, initialize it:\\n\\n```bash\\nfclt templates init operating-model --global\\n```\\n\\n3. If a repo needs local capability, initialize project AI:\\n\\n```bash\\nfclt templates init project-ai\\n```\\n\\n4. Refresh pack defaults non-destructively:\\n\\n```bash\\nfclt templates init operating-model --global --update --dry-run\\nfclt templates init operating-model --global --update\\n```\\n\\n5. Use `--force` only when the user explicitly wants to replace local edits.\\n\\n## Rules\\n\\n- Preserve existing `AGENTS.md`, `CLAUDE.md`, and `AGENTS.global.md` guidance.\\n- First install should seed from existing agent guidance when available.\\n- Treat `doctor --json` issues as setup facts, not user-facing blame.\\n- Prefer temp-root smoke tests for install/update behavior.\\n- Do not enable managed rendering unless the user wants fclt to write tool homes.\\n\\n## Output\\n\\n- current installed version\\n- setup health\\n- paths that matter\\n- commands run\\n- what changed\\n- what still needs approval\\n","skills/fclt-writeback/SKILL.md":"---\\ndescription: Record and review fclt writebacks from real agent work.\\ntags: [fclt, writeback, learning, feedback-loop]\\n---\\n\\n# fclt-writeback\\n\\n## When To Use\\nUse this skill when work reveals durable friction, missing context, weak verification, stale guidance, repeated success, or a capability gap.\\n\\nWriteback is for preserving signal. It is not for every preference or one-off annoyance.\\n\\n## Workflow\\n\\n1. Decide scope:\\n\\n- `project` when the learning depends on a repo, test harness, architecture, or workflow.\\n- `global` when the learning applies across projects or shared tool behavior.\\n\\n2. Choose the smallest target:\\n\\n- instruction\\n- snippet\\n- skill\\n- agent\\n- MCP/tool config\\n- automation\\n\\n3. Record writeback when the target and evidence are clear:\\n\\n```bash\\nfclt ai writeback add --kind missing_context --summary \\"...\\" --asset @project/instructions/TESTING.md\\n```\\n\\n4. Review current signal:\\n\\n```bash\\nfclt ai writeback list\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\n```\\n\\n## Rules\\n\\n- Prefer one high-signal writeback over several weak ones.\\n- Include concrete evidence when possible.\\n- Do not copy private project detail into global writebacks.\\n- Use task tracking for executable product/tooling work; use writeback for reusable operating-layer learning.\\n- If the same signal repeats and the target is clear, hand off to `fclt-evolution`.\\n\\n## Output\\n\\n- writeback id or no-op rationale\\n- scope\\n- target asset\\n- evidence summary\\n- whether this is ready for evolution\\n"}'
+  '{".codex-plugin/plugin.json":"{\\n  \\"name\\": \\"fclt\\",\\n  \\"version\\": \\"0.1.0\\",\\n  \\"description\\": \\"Codex workflows and MCP tools for fclt setup, writeback, evolution, and capability review.\\",\\n  \\"license\\": \\"MIT\\",\\n  \\"keywords\\": [\\n    \\"fclt\\",\\n    \\"facult\\",\\n    \\"codex\\",\\n    \\"skills\\",\\n    \\"mcp\\",\\n    \\"writeback\\",\\n    \\"evolution\\"\\n  ],\\n  \\"skills\\": \\"./skills/\\",\\n  \\"mcpServers\\": \\"./.mcp.json\\",\\n  \\"interface\\": {\\n    \\"displayName\\": \\"fclt\\",\\n    \\"shortDescription\\": \\"Capability loops for Codex\\",\\n    \\"longDescription\\": \\"Install and operate fclt from Codex: initialize AI capability roots, inspect setup health, record writebacks, review evolution proposals, and keep skills, snippets, instructions, automations, and MCP surfaces improving over time.\\",\\n    \\"developerName\\": \\"Hack Dance\\",\\n    \\"category\\": \\"Productivity\\",\\n    \\"capabilities\\": [\\"Read\\", \\"Write\\", \\"MCP\\"],\\n    \\"defaultPrompt\\": [\\n      \\"Use fclt to check this repo\'s AI capability setup.\\",\\n      \\"Record useful fclt writeback from this work.\\",\\n      \\"Review fclt evolution proposals and next actions.\\"\\n    ],\\n    \\"brandColor\\": \\"#166534\\"\\n  }\\n}\\n",".mcp.json":"{\\n  \\"mcpServers\\": {\\n    \\"fclt\\": {\\n      \\"command\\": \\"node\\",\\n      \\"args\\": [\\"./scripts/fclt-mcp.cjs\\"],\\n      \\"env\\": {\\n        \\"FCLT_BIN\\": \\"fclt\\"\\n      }\\n    }\\n  }\\n}\\n","scripts/fclt-mcp.cjs":"#!/usr/bin/env node\\n\\"use strict\\";\\n\\nconst { spawn } = require(\\"node:child_process\\");\\n\\nconst FCLT_BIN = process.env.FCLT_BIN || \\"fclt\\";\\nconst DEFAULT_TIMEOUT_MS = Number(process.env.FCLT_MCP_TIMEOUT_MS || 60_000);\\nconst CONTENT_LENGTH_RE = /Content-Length:\\\\s*(\\\\d+)/i;\\n\\nconst tools = [\\n  {\\n    name: \\"fclt_status\\",\\n    description:\\n      \\"Return fclt status for the current, global, or project scope.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_doctor\\",\\n    description: \\"Run read-only fclt doctor checks and return JSON output.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_paths\\",\\n    description: \\"Return canonical, generated, review, and runtime fclt paths.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_init_operating_model\\",\\n    description: \\"Install or update the built-in operating-model pack.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        update: { type: \\"boolean\\" },\\n        dryRun: { type: \\"boolean\\" },\\n        force: { type: \\"boolean\\" },\\n      },\\n      required: [\\"scope\\"],\\n    },\\n  },\\n  {\\n    name: \\"fclt_writeback_add\\",\\n    description: \\"Record a durable fclt writeback with evidence.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        kind: { type: \\"string\\" },\\n        summary: { type: \\"string\\" },\\n        asset: { type: \\"string\\" },\\n        evidence: { type: \\"string\\" },\\n        confidence: {\\n          type: \\"string\\",\\n          enum: [\\"low\\", \\"medium\\", \\"high\\"],\\n        },\\n      },\\n      required: [\\"kind\\", \\"summary\\"],\\n    },\\n  },\\n  {\\n    name: \\"fclt_writeback_review\\",\\n    description: \\"List, group, or summarize current fclt writebacks.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        mode: { type: \\"string\\", enum: [\\"list\\", \\"group\\", \\"summarize\\"] },\\n        by: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n  {\\n    name: \\"fclt_evolve\\",\\n    description:\\n      \\"Assess, list, propose, draft, or review fclt evolution proposals.\\",\\n    inputSchema: {\\n      type: \\"object\\",\\n      properties: {\\n        scope: { type: \\"string\\", enum: [\\"auto\\", \\"global\\", \\"project\\"] },\\n        cwd: { type: \\"string\\" },\\n        action: {\\n          type: \\"string\\",\\n          enum: [\\"assess\\", \\"list\\", \\"propose\\", \\"draft\\", \\"review\\", \\"show\\"],\\n        },\\n        id: { type: \\"string\\" },\\n        asset: { type: \\"string\\" },\\n      },\\n    },\\n  },\\n];\\n\\nfunction scopeArgs(scope) {\\n  if (scope === \\"global\\") {\\n    return [\\"--global\\"];\\n  }\\n  if (scope === \\"project\\") {\\n    return [\\"--project\\"];\\n  }\\n  return [];\\n}\\n\\nfunction boolFlag(name, value) {\\n  return value ? [name] : [];\\n}\\n\\nfunction stringFlag(name, value) {\\n  return typeof value === \\"string\\" && value.trim() ? [name, value] : [];\\n}\\n\\nfunction commandForTool(name, args = {}) {\\n  switch (name) {\\n    case \\"fclt_status\\":\\n      return [\\"status\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_doctor\\":\\n      return [\\"doctor\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_paths\\":\\n      return [\\"paths\\", ...scopeArgs(args.scope), \\"--json\\"];\\n    case \\"fclt_init_operating_model\\":\\n      return [\\n        \\"templates\\",\\n        \\"init\\",\\n        \\"operating-model\\",\\n        ...scopeArgs(args.scope),\\n        ...boolFlag(\\"--update\\", args.update),\\n        ...boolFlag(\\"--dry-run\\", args.dryRun),\\n        ...boolFlag(\\"--force\\", args.force),\\n        \\"--json\\",\\n      ];\\n    case \\"fclt_writeback_add\\":\\n      return [\\n        \\"ai\\",\\n        \\"writeback\\",\\n        ...scopeArgs(args.scope),\\n        \\"add\\",\\n        \\"--kind\\",\\n        args.kind,\\n        \\"--summary\\",\\n        args.summary,\\n        ...stringFlag(\\"--asset\\", args.asset),\\n        ...stringFlag(\\"--evidence\\", args.evidence),\\n        ...stringFlag(\\"--confidence\\", args.confidence),\\n      ];\\n    case \\"fclt_writeback_review\\": {\\n      const mode = args.mode || \\"list\\";\\n      return [\\n        \\"ai\\",\\n        \\"writeback\\",\\n        ...scopeArgs(args.scope),\\n        mode,\\n        ...stringFlag(\\"--by\\", args.by),\\n      ];\\n    }\\n    case \\"fclt_evolve\\": {\\n      const action = args.action || \\"list\\";\\n      return [\\n        \\"ai\\",\\n        \\"evolve\\",\\n        ...scopeArgs(args.scope),\\n        action,\\n        ...(action === \\"assess\\" || action === \\"propose\\"\\n          ? stringFlag(\\"--asset\\", args.asset)\\n          : []),\\n        ...(args.id ? [args.id] : []),\\n        ...(action === \\"assess\\" ? [\\"--json\\"] : []),\\n      ];\\n    }\\n    default:\\n      throw new Error(`Unknown tool: ${name}`);\\n  }\\n}\\n\\nfunction runFclt(args, cwd) {\\n  return new Promise((resolve) => {\\n    const child = spawn(FCLT_BIN, args, {\\n      cwd: cwd || process.cwd(),\\n      env: process.env,\\n      stdio: [\\"ignore\\", \\"pipe\\", \\"pipe\\"],\\n    });\\n    let stdout = \\"\\";\\n    let stderr = \\"\\";\\n    const timer = setTimeout(() => {\\n      child.kill(\\"SIGTERM\\");\\n    }, DEFAULT_TIMEOUT_MS);\\n    child.stdout.on(\\"data\\", (chunk) => {\\n      stdout += chunk.toString();\\n    });\\n    child.stderr.on(\\"data\\", (chunk) => {\\n      stderr += chunk.toString();\\n    });\\n    child.on(\\"close\\", (code) => {\\n      clearTimeout(timer);\\n      resolve({\\n        code,\\n        text: [\\n          `$ ${FCLT_BIN} ${args.join(\\" \\")}`,\\n          stdout.trim(),\\n          stderr.trim() ? `stderr:\\\\n${stderr.trim()}` : \\"\\",\\n        ]\\n          .filter(Boolean)\\n          .join(\\"\\\\n\\\\n\\"),\\n      });\\n    });\\n  });\\n}\\n\\nfunction send(message) {\\n  const body = JSON.stringify(message);\\n  process.stdout.write(\\n    `Content-Length: ${Buffer.byteLength(body)}\\\\r\\\\n\\\\r\\\\n${body}`\\n  );\\n}\\n\\nasync function handle(message) {\\n  if (!message || message.id == null) {\\n    return;\\n  }\\n\\n  try {\\n    if (message.method === \\"initialize\\") {\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: message.id,\\n        result: {\\n          protocolVersion: \\"2025-06-18\\",\\n          capabilities: { tools: {} },\\n          serverInfo: { name: \\"fclt\\", version: \\"0.1.0\\" },\\n        },\\n      });\\n      return;\\n    }\\n    if (message.method === \\"tools/list\\") {\\n      send({ jsonrpc: \\"2.0\\", id: message.id, result: { tools } });\\n      return;\\n    }\\n    if (message.method === \\"tools/call\\") {\\n      const { name, arguments: args = {} } = message.params || {};\\n      const command = commandForTool(name, args);\\n      const result = await runFclt(command, args.cwd);\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: message.id,\\n        result: {\\n          isError: result.code !== 0,\\n          content: [{ type: \\"text\\", text: result.text }],\\n        },\\n      });\\n      return;\\n    }\\n    send({\\n      jsonrpc: \\"2.0\\",\\n      id: message.id,\\n      error: { code: -32_601, message: `Method not found: ${message.method}` },\\n    });\\n  } catch (error) {\\n    send({\\n      jsonrpc: \\"2.0\\",\\n      id: message.id,\\n      error: {\\n        code: -32_000,\\n        message: error instanceof Error ? error.message : String(error),\\n      },\\n    });\\n  }\\n}\\n\\nlet buffer = Buffer.alloc(0);\\n\\nprocess.stdin.on(\\"data\\", (chunk) => {\\n  buffer = Buffer.concat([buffer, chunk]);\\n  while (true) {\\n    const headerEnd = buffer.indexOf(\\"\\\\r\\\\n\\\\r\\\\n\\");\\n    if (headerEnd === -1) {\\n      return;\\n    }\\n    const header = buffer.slice(0, headerEnd).toString(\\"utf8\\");\\n    const match = CONTENT_LENGTH_RE.exec(header);\\n    if (!match) {\\n      buffer = Buffer.alloc(0);\\n      return;\\n    }\\n    const length = Number(match[1]);\\n    const frameEnd = headerEnd + 4 + length;\\n    if (buffer.length < frameEnd) {\\n      return;\\n    }\\n    const body = buffer.slice(headerEnd + 4, frameEnd).toString(\\"utf8\\");\\n    buffer = buffer.slice(frameEnd);\\n    handle(JSON.parse(body)).catch((error) => {\\n      send({\\n        jsonrpc: \\"2.0\\",\\n        id: null,\\n        error: {\\n          code: -32_000,\\n          message: error instanceof Error ? error.message : String(error),\\n        },\\n      });\\n    });\\n  }\\n});\\n\\nif (process.argv.includes(\\"--self-test\\")) {\\n  console.log(\\n    JSON.stringify({ tools: tools.map((tool) => tool.name) }, null, 2)\\n  );\\n  process.exit(0);\\n}\\n","skills/fclt-capability-review/SKILL.md":"---\\ndescription: Inspect fclt capability roots, docs, snippets, skills, agents, MCP, and automations.\\ntags: [fclt, capability, review, inventory]\\n---\\n\\n# fclt-capability-review\\n\\n## When To Use\\nUse this skill when Codex needs to understand what capability exists before changing it.\\n\\nUse it for:\\n\\n- checking global and project `.ai` roots\\n- finding relevant skills, snippets, instructions, agents, MCP servers, or automations\\n- deciding whether a change belongs in global or project scope\\n- checking whether managed rendering is enabled or needed\\n- reviewing public/private boundaries before publishing docs or pack assets\\n\\n## Workflow\\n\\n```bash\\nfclt status --json\\nfclt inventory --json\\nfclt list skills\\nfclt list instructions\\nfclt list snippets\\nfclt graph AGENTS.global.md\\n```\\n\\nFor project work:\\n\\n```bash\\nfclt status --project --json\\nfclt inventory --project --json\\n```\\n\\n## Rules\\n\\n- Read existing repo guidance before proposing project capability.\\n- Use project scope for repo-specific commands, tests, architecture, or team workflow.\\n- Use global scope only for broadly reusable behavior.\\n- Keep generated state and review artifacts out of repo-local `.ai`.\\n- Prefer adding or updating the smallest unit: instruction, snippet, skill, agent, MCP config, or automation.\\n\\n## Output\\n\\n- capability roots found\\n- relevant assets\\n- scope recommendation\\n- missing or stale capability\\n- safe next command\\n","skills/fclt-evolution/SKILL.md":"---\\ndescription: Turn repeated fclt writebacks into reviewed capability changes.\\ntags: [fclt, evolution, proposals, capability]\\n---\\n\\n# fclt-evolution\\n\\n## When To Use\\nUse this skill when repeated writebacks, stale canonical assets, or a clearly missing capability should become a concrete proposal.\\n\\nDo not use it for a single weak preference or speculative idea.\\n\\n## Workflow\\n\\n1. Review signal:\\n\\n```bash\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\nfclt ai evolve list\\n```\\n\\n2. Assess proposal readiness before mutating state:\\n\\n```bash\\nfclt ai evolve assess --asset <selector> --json\\n```\\n\\nUse the assessment recommendation as the decision checkpoint:\\n\\n- `no_mutation`: do not change capability state; ask for a target or evidence.\\n- `record_more_writeback`: explain what recurrence would justify evolution and record a new writeback only if there is fresh concrete evidence.\\n- `propose`: ask before running the proposal command, then create the smallest target-specific proposal.\\n- `review_existing_proposal`: inspect or revise the existing proposal instead of creating a duplicate.\\n\\n3. Propose only when evidence is strong enough:\\n\\n```bash\\nfclt ai evolve propose\\n```\\n\\n4. Draft and inspect:\\n\\n```bash\\nfclt ai evolve draft EV-00001\\nfclt ai evolve review EV-00001\\n```\\n\\n5. Accept/apply only when scope, target, and evidence are correct:\\n\\n```bash\\nfclt ai evolve accept EV-00001\\nfclt ai evolve apply EV-00001\\n```\\n\\n## Proposal Kinds\\n\\n- `update_asset`\\n- `create_asset`\\n- `extract_snippet`\\n- `add_skill`\\n- `promote_asset`\\n\\n## Rules\\n\\n- Prefer the smallest valid proposal kind.\\n- Keep project-specific behavior project-scoped until reuse is proven.\\n- Ask for approval before applying global instructions, global skills, plugin behavior, or other broad shared surfaces.\\n- Reject or park proposals that are stale, duplicated, vague, or unsupported.\\n- Use Linear or another task system for executable implementation work that needs owner, priority, or state.\\n- A no-op answer must still be useful: include the evidence grade, missing signal, next writeback target, and exact approval boundary.\\n\\n## Output\\n\\n- proposals reviewed\\n- repeated signal\\n- assessment recommendation\\n- proposal created or updated\\n- approvals needed\\n- apply/reject/no-op rationale\\n","skills/fclt-setup/SKILL.md":"---\\ndescription: Install, update, inspect, and initialize fclt from Codex.\\ntags: [fclt, setup, codex, onboarding]\\n---\\n\\n# fclt-setup\\n\\n## When To Use\\nUse this skill when a user wants Codex to install, update, configure, inspect, or repair fclt.\\n\\nUse it for:\\n\\n- checking whether `fclt` is installed and current\\n- initializing global `~/.ai` or project `<repo>/.ai`\\n- installing or refreshing the built-in operating-model pack\\n- checking setup health with `doctor`\\n- finding canonical, generated, runtime, and review paths\\n\\n## Workflow\\n\\n1. Check current state:\\n\\n```bash\\nfclt --version\\nfclt paths --json\\nfclt doctor --json\\n```\\n\\n2. If global capability is missing, initialize it:\\n\\n```bash\\nfclt templates init operating-model --global\\n```\\n\\n3. If a repo needs local capability, initialize project AI:\\n\\n```bash\\nfclt templates init project-ai\\n```\\n\\n4. Refresh pack defaults non-destructively:\\n\\n```bash\\nfclt templates init operating-model --global --update --dry-run\\nfclt templates init operating-model --global --update\\n```\\n\\n5. Use `--force` only when the user explicitly wants to replace local edits.\\n\\n## Rules\\n\\n- Preserve existing `AGENTS.md`, `CLAUDE.md`, and `AGENTS.global.md` guidance.\\n- First install should seed from existing agent guidance when available.\\n- Treat `doctor --json` issues as setup facts, not user-facing blame.\\n- Prefer temp-root smoke tests for install/update behavior.\\n- Do not enable managed rendering unless the user wants fclt to write tool homes.\\n\\n## Output\\n\\n- current installed version\\n- setup health\\n- paths that matter\\n- commands run\\n- what changed\\n- what still needs approval\\n","skills/fclt-writeback/SKILL.md":"---\\ndescription: Record and review fclt writebacks from real agent work.\\ntags: [fclt, writeback, learning, feedback-loop]\\n---\\n\\n# fclt-writeback\\n\\n## When To Use\\nUse this skill when work reveals durable friction, missing context, weak verification, stale guidance, repeated success, or a capability gap.\\n\\nWriteback is for preserving signal. It is not for every preference or one-off annoyance.\\n\\n## Workflow\\n\\n1. Decide scope:\\n\\n- `project` when the learning depends on a repo, test harness, architecture, or workflow.\\n- `global` when the learning applies across projects or shared tool behavior.\\n\\n2. Choose the smallest target:\\n\\n- instruction\\n- snippet\\n- skill\\n- agent\\n- MCP/tool config\\n- automation\\n\\n3. Record writeback when the target and evidence are clear:\\n\\n```bash\\nfclt ai writeback add --kind missing_context --summary \\"...\\" --asset @project/instructions/TESTING.md\\n```\\n\\n4. Review current signal:\\n\\n```bash\\nfclt ai writeback list\\nfclt ai writeback group --by asset\\nfclt ai writeback summarize --by domain\\n```\\n\\n## Rules\\n\\n- Prefer one high-signal writeback over several weak ones.\\n- Include concrete evidence when possible.\\n- Do not copy private project detail into global writebacks.\\n- Use task tracking for executable product/tooling work; use writeback for reusable operating-layer learning.\\n- If the same signal repeats and the target is clear, hand off to `fclt-evolution`.\\n\\n## Output\\n\\n- writeback id or no-op rationale\\n- scope\\n- target asset\\n- evidence summary\\n- whether this is ready for evolution\\n"}'
 ) as Record<string, string>;