facult 2.5.0 → 2.5.1

package/README.md

@@ -282,6 +282,8 @@ bunx fclt index
 
 This seeds `<repo>/.ai` from the built-in Facult operating-model pack and writes a merged project index/graph under `<repo>/.ai/.facult/ai/`.
 
+Wide learning-review automations should use this same bootstrap when they hit a local writable repo with durable project-local signal but no repo-local `.ai` yet.
+
 ### 4. Inspect what you have
 
 ```bash

package/package.json

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

package/src/cli-context.ts

@@ -16,6 +16,11 @@ export interface ParsedCliContext {
   sourceKind?: AssetSourceKind;
 }
 
+function missingProjectAiRootMessage(pathValue?: string): string {
+  const suffix = pathValue ? `: ${pathValue}` : "";
+  return `No project-local .ai root found${suffix}. Run "fclt templates init project-ai" in the repo first, or pass --root <repo>/.ai.`;
+}
+
 function expandHomePath(pathValue: string, home: string): string {
   if (pathValue === "~") {
     return home;
@@ -173,9 +178,7 @@ export function resolveCliContextRoot(args?: {
   if (args?.rootArg) {
     const rootDir = coerceCanonicalRoot(args.rootArg, homeDir);
     if (scope === "project" && !projectRootFromAiRoot(rootDir, homeDir)) {
-      throw new Error(
-        `Project scope requires a repo-local .ai root: ${rootDir}`
-      );
+      throw new Error(missingProjectAiRootMessage(rootDir));
     }
     return rootDir;
   }
@@ -187,9 +190,7 @@ export function resolveCliContextRoot(args?: {
   if (scope === "project") {
     const projectRoot = findNearestProjectAiRoot(cwd);
     if (!projectRoot) {
-      throw new Error(
-        "No project-local .ai root found from the current directory"
-      );
+      throw new Error(missingProjectAiRootMessage(cwd));
     }
     return projectRoot;
   }

package/src/remote.ts

@@ -341,7 +341,7 @@ Use this memory for pattern continuity:
 - For wide reviews, partition evidence by cwd first; do not let one repo's evidence stand in for another.
 - Grounding: prefer evidence from session messages, tool calls, shell commands, diffs, tests, commits, and touched files.
 - Threshold: only encode signal when you can name what was learned, why it matters, and the most plausible destination.
-- Scope: default to project writeback unless the signal clearly belongs in global doctrine or a shared capability.
+- Scope: default to project writeback only when the repo has a project-local \`.ai\` root. If a local writable repo is missing one, bootstrap baseline project AI state with \`fclt templates init project-ai\` before retrying project-scoped writeback. If bootstrap fails or the repo is not writable, treat that as the blocker instead of silently falling back to global runtime state.
 - Promote to global only when the same signal appears across multiple repos or clearly targets shared doctrine, shared agents, or shared skills.
 - Verification: distinguish one-off friction from a repeated pattern before escalating it.
 - If available, use [$feedback-loop-setup]({{feedbackLoopSkill}}) when the review needs stronger feedback loops or verification framing.
@@ -367,6 +367,8 @@ Grounding rules:
 
 Decision rules:
 - Use \`fclt ai writeback add\` when the signal, target asset, and scope are clear.
+- Before attempting project-scoped writeback, verify the cwd has a repo-local \`.ai\` root. If it does not and the cwd is a local writable repo, run \`fclt templates init project-ai\` from that repo root, then continue. If bootstrap fails or the repo is not writable, report the writeback as blocked by missing project AI state rather than falling back to merged/global runtime state.
+- Before passing \`--asset\`, verify the target resolves in the Facult graph. If the destination is a raw file path or otherwise not graph-backed, report that as a missing-asset blocker instead of retrying blind.
 - Use \`fclt ai evolve\` only when repeated signal is strong enough to justify a reviewable capability change.
 - Prefer project scope unless the learning clearly belongs in shared global doctrine, shared agents, shared skills, or other cross-project capability.
 - For wide automations, require repeated evidence across more than one cwd before recommending a global/shared capability change unless the target is obviously global.