feed-the-machine 1.7.3 → 1.7.5

package/ftm-mind/references/orient-protocol.md

@@ -179,16 +179,70 @@ Ask the user only when one of these is true:
 
 - two materially different interpretations are both plausible
 - an external-facing action needs approval
-- a required credential, path, or identifier is missing
+- a required credential, path, or identifier is missing **AND the blackboard has no experience confirming access** (see Blackboard-First Rule below)
 - the user explicitly asked for options before action
-- **the task is medium+ and involves external systems, stakeholder coordination, or unfamiliar code** (see Discovery Interview below)
+- **the task is medium+ and involves external systems, stakeholder coordination, or unfamiliar code** (see Discovery Interview below) **AND the blackboard doesn't already confirm repo-level access**
 
 When asking, ask one focused question with concrete choices.
 
+### Blackboard-First Rule (MANDATORY before any access/auth questions)
+
+**Before asking ANY question about credentials, API access, authorization, permissions, or "do you have access to X" — check the blackboard first.**
+
+1. Read `experiences/index.json`
+2. Look for entries tagged with the current repo name, `api-access`, `full-access`, `credentials`, or the system being asked about (e.g., `freshservice`, `okta`, `jira`)
+3. If a matching experience exists with `confidence >= 0.7`:
+   - **Do NOT ask about access.** The user already established this.
+   - **Do NOT run a discovery interview about authorization.** You have the answer.
+   - **Just do the thing.** If the credentials don't work, you'll find out when the API call fails — and that's a better signal than a speculative question.
+4. If no matching experience exists, proceed with asking.
+
+This rule exists because users set up repo-level context once (e.g., "ragnarok has full Okta/Freshservice/Jira API access") and expect Claude to remember it across every session. Asking "do you have admin access?" when the blackboard already says "yes, full access" is the #1 frustration signal.
+
+### Access Declaration Detection (MANDATORY)
+
+When a user declares repo-level access — either explicitly or as part of a task — **immediately write a blackboard experience so it persists across sessions.** Do NOT wait until the task is complete. Write it during Orient, before acting.
+
+**Detection triggers** (any of these in the user's message):
+- "I have access to...", "I have credentials for...", "I'm authenticated to..."
+- "this repo has access to...", "we have API keys for..."
+- "just do it, I have the creds", "you have access here", "credentials are configured"
+- "I'm in [repo name] with my credentials"
+- The user tells you to stop asking and just use an API
+- An API call succeeds for the first time in a repo where no access experience exists
+
+**What to write** — create an experience file at `~/.claude/ftm-state/blackboard/experiences/learning-{repo-name}-api-access.json`:
+
+```json
+{
+  "id": "learning-{repo-name}-api-access",
+  "timestamp": "{ISO 8601 now}",
+  "task_type": "environment-knowledge",
+  "tags": ["{repo-name}", "api-access", "environment", "learning"],
+  "outcome": "success",
+  "description": "User confirmed API access in {repo-name} repo. {any specifics they mentioned — which systems, what kind of access}.",
+  "lessons": [
+    "{repo-name} repo has configured access to {systems mentioned}",
+    "Do not ask about credentials or authorization when working in this repo — just act"
+  ],
+  "confidence": 1.0,
+  "code_patterns": [],
+  "api_gotchas": []
+}
+```
+
+Also update `experiences/index.json` with the new entry.
+
+**On first successful API call:** If you make an API call in a repo and it succeeds, but no access experience exists for this repo, write one automatically. The success IS the proof of access. Tag it with the repo name and the system that worked (e.g., `freshservice`, `okta`).
+
+**This is not optional.** Every repo where the user has confirmed access should have exactly one `learning-{repo-name}-api-access.json` experience. This is what makes the Blackboard-First Rule work for new users, not just for users who had their experiences manually seeded.
+
 ### Discovery Interview (medium+ tasks with external systems)
 
 When a task hits forced-medium or higher AND involves external systems, stakeholder coordination, or code you haven't read yet this session, run a brief discovery interview BEFORE generating the plan. The interview surfaces hidden requirements the user knows but hasn't stated.
 
+**Before running the interview, apply the Blackboard-First Rule above.** If the blackboard confirms access and the task is a straightforward API operation (add user, create ticket, update group), skip the interview entirely and just do it. The interview is for tasks with genuine unknowns — stakeholder coordination, multi-system migrations, policy changes — not for "use the Freshservice API to add an agent."
+
 The interview should be 2-4 focused questions:
 
 - Who else needs to know about this change?
@@ -201,6 +255,7 @@ The interview should be 2-4 focused questions:
 - The user already provided comprehensive context
 - The task is purely local with no external dependencies
 - The user explicitly says "just do it" or "no questions, go"
+- **The blackboard has an experience confirming API access for this repo + the task is a direct API operation** (not stakeholder coordination or multi-system migration)
 
 ## Brain.py Task Loading (Observe Phase)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "feed-the-machine",
-  "version": "1.7.3",
+  "version": "1.7.5",
   "description": "A brain upgrade for Claude Code — 26 skills that teach it how to think before acting, remember across conversations, debug like a war room, run plans on autopilot with agent teams, and get second opinions from GPT & Gemini. Plus 15 hooks that automate the boring stuff.",
   "license": "MIT",
   "author": "kkudumu",