@elevasis/sdk 1.44.2 → 1.45.0

package/reference/claude-config/sync-notes/2026-08-03-cli-gateway-errors-and-request-timeout.md

@@ -1,120 +0,0 @@
-# Your CLI now explains a 502 instead of just reporting one, and no request hangs forever
-
-## Why this note exists
-
-This train publishes one package — `@elevasis/sdk` — and every change in it is in the CLI you type
-commands into. Nothing about your workflows, organization model, or UI moves. But the CLI's failure
-messages change, and one of them changes in a way that is meant to stop you doing something harmful.
-
-**1. A gateway failure now tells you the work may still be running, and how to check.** Until now
-every non-2xx response produced the same shape: `API request failed (502)`. That message is
-technically accurate and practically dangerous, because the most natural reaction to it is to run the
-command again.
-
-A 502, 503, or 504 does not come from the platform API. It comes from a hop in front of it that ended
-your connection while the API was still working. The request you sent may have completed in full. We
-found this the hard way: a session turn returned 502 to the CLI after 300 seconds, and a later
-database query showed the turn had **completed successfully server-side in 319.8 seconds** with a
-model reply written and no error of any kind. The only thing that failed was the connection carrying
-the answer back. It was turn 14 of a 14-turn run — re-running blind would have executed that turn a
-second time.
-
-The new message says the proxy ended the connection, that this is not the API rejecting your request,
-that the work may still be running, and which command to use to look for a result before re-running.
-
-**2. Every CLI request is now bounded by a timeout, defaulting to 2 hours.** Before, the CLI used a
-bare `fetch()` with no signal, so a connection that stalled would sit there indefinitely with no
-output. The limit is deliberately set high — it matches the server's own socket budget on long routes.
-The goal is to bound an indefinite hang, not to police how long your work may take. Anything shorter
-would make the CLI give up on executions the API is still legitimately serving, turning a working long
-run into a reported failure. Override it with `ELEVASIS_CLI_TIMEOUT_MS` if you have a reason to.
-
-**3. "Timed out" and "never reached the API" are now different messages.** A bare `fetch()` rejection
-carries no status, so a dead port, a wrong API URL, and a stalled connection were indistinguishable.
-They now read differently.
-
-**4. The friendly authentication message now applies to every verb.** A 401 on `GET` printed a clear
-"check your platform key" message; a 401 on `POST`, `PATCH`, or `DELETE` printed the raw response
-body. All four now share the same message.
-
-**5. Three dead exports were removed from the agent memory surface.** `MEMORY_DOMAINS.ACTION_OWNED`
-was an empty array, `isActionOwnedKey` returned `false` for every input, and the `ActionOwnedKey` type
-resolved to `never`. They are gone. The live half of that layer is unchanged and still enforced: an
-agent still cannot write to a tool-owned memory key. If your project imports any of the three removed
-names, it was importing something that could never do anything — but the import will now fail, so it
-is worth a grep.
-
-## Applies to
-
-- **Every project that uses the `elevasis-sdk` CLI**, which is every template-family project. Items 1
-  through 4 arrive with the baseline bump and need no source edit from you.
-- **Any script or CI job that parses CLI stderr.** The gateway, timeout, and transport messages are
-  new text. If something greps for `API request failed`, check it.
-- **Any project importing `ACTION_OWNED`, `isActionOwnedKey`, or `ActionOwnedKey`** from the SDK, for
-  item 5. We found no such import in any template-family project, but only you can see out-of-tree
-  code.
-- **Not applicable to your organization model, knowledge nodes, workflows, or UI.** Nothing in this
-  train touches authored content or any rendered surface.
-
-## Required actions
-
-1. **Take the `@elevasis/sdk` baseline bump** this train propagates, then reinstall in `operations/`:
-
-   ```bash
-   pnpm -C operations install
-   ```
-
-2. **Grep for the three removed memory exports** before you deploy. This is the only change in the
-   train that can break a build, and it is cheap to rule out:
-
-   ```bash
-   grep -rn "ACTION_OWNED\|isActionOwnedKey\|ActionOwnedKey" operations/src core/config
-   ```
-
-   No output means item 5 does not affect you.
-
-3. **Redeploy `operations/`.** The baseline bump changes what your next bundle contains; it does not
-   change what is already deployed:
-
-   ```bash
-   pnpm -C operations exec elevasis-sdk deploy
-   ```
-
-4. **Check any script that matches on CLI error text.** If you have automation that branches on
-   `API request failed`, it will no longer match a gateway failure.
-
-## Verification
-
-- **Read the installed bundle, not the version number.** A bumped pin and a green sync report are
-  claims about intent; the installed file is the only ground truth:
-
-  ```bash
-  grep -c "GATEWAY_STATUSES" operations/node_modules/@elevasis/sdk/dist/cli.cjs
-  grep -c "ACTION_OWNED" operations/node_modules/@elevasis/sdk/dist/worker/index.js
-  ```
-
-  The first must be non-zero and the second must be `0`. Either result the other way means the
-  install did not land, regardless of what `package.json` says.
-
-- **Provoke a transport failure and read the message.** The cheapest honest check that the new
-  branches are live, because it needs no broken server:
-
-  ```bash
-  ELEVASIS_API_URL=http://localhost:9 pnpm -C operations exec elevasis-sdk list
-  ```
-
-  You should get a message naming the endpoint and saying the request never reached the API — not a
-  bare `fetch failed`.
-
-- **Confirm the timeout is configurable.** Setting `ELEVASIS_CLI_TIMEOUT_MS=1` on any command should
-  produce a timeout message that quotes the limit back to you.
-
-## Not handled by /git-sync
-
-- **The `operations/` reinstall.** `/git-sync` propagates and commits the dependency baseline. The
-  `node_modules` copy your CLI actually executes is not updated until you run `pnpm install` yourself,
-  and the CLI will keep printing the old messages until you do.
-- **The `operations/` redeploy.** Bumping the `@elevasis/sdk` pin changes what your next bundle
-  contains. Your currently deployed workers keep running the old bundle until you deploy.
-- **The grep for the removed memory exports.** Nothing can detect an out-of-tree import for you.
-- **Updating scripts that match on CLI error text.** The sync cannot see your automation.

package/reference/claude-config/sync-notes/README.md

@@ -1,43 +0,0 @@
-# Sync Notes
-
-Template-owned downstream migration guidance lives in this directory.
-
-## File Contract
-
-- Operative note files must be named `YYYY-MM-DD-<slug>.md`
-- `README.md` explains the contract and is ignored by `/git-sync`
-- Notes are append-only. Add a new dated file for each downstream-affecting release train instead of rewriting an older note
-
-## When A Note Is Mandatory
-
-Add a new operative note whenever a train affects derived projects beyond a normal pull, install, and baseline verify. Common triggers:
-
-- template dependency-baseline changes
-- scaffold or sync-contract changes
-- rename or migration work
-- verifier or behavior changes that downstream maintainers need to understand
-- any release train that will ask maintainers to do manual follow-up after pulling
-
-## Required Sections
-
-Every operative note must include these exact headings:
-
-## Why this note exists
-
-Explain what changed and why downstream maintainers are seeing this note.
-
-## Applies to
-
-State which projects, app modes, or versions need the follow-up.
-
-## Required actions
-
-List the manual work maintainers need to do after `/git-sync`.
-
-## Verification
-
-List the commands or flows that confirm the migration landed correctly.
-
-## Not handled by /git-sync
-
-Call out what remains manual so maintainers do not assume the pull/install/verify flow reconciled everything.

package/reference/sdk/framework/interaction-guidance.mdx

@@ -1,182 +0,0 @@
----
-title: "Interaction Guidance"
-description: "Full dimensional adaptation rules per skill axis -- platform navigation, API integration, automation concepts, domain expertise -- with growth tracking protocol"
-loadWhen: "Unsure how to adapt for a skill combination"
----
-
-This reference defines how to adapt every interaction based on the dimensions in `.claude/memory/profile/skills.md`. Read it when the compact directive in CLAUDE.md is not enough to decide how to handle an unusual skill combination.
-
----
-
-## Skill Dimensions
-
-The user profile stores four independent skill dimensions. Each dimension has its own adaptation rules. Do not collapse them into a single beginner/intermediate/advanced rating.
-
-### Platform Navigation (none / oriented / comfortable)
-
-**none** -- Never used the Command Center. Does not know where pages are.
-
-- Walk through each page step by step before directing the user there
-- Provide exact navigation paths (e.g., "Open the Command Center, then click Execution Runner in the left sidebar")
-- Explain what each page does before asking them to use it
-- Do not assume they can find a page by name alone
-
-**oriented** -- Has explored the Command Center, knows the main sections.
-
-- Reference pages by name (Execution Runner, Command Queue, Task Scheduler)
-- Briefly remind the user what a page does on first mention in a session
-- Trust them to navigate once you name the destination
-
-**comfortable** -- Regularly uses the Command Center without guidance.
-
-- Reference pages by name only, no reminders needed
-- Focus on advanced filtering, schedule types, and log detail navigation
-- Trust them to explore and navigate independently
-
----
-
-### API and Integration (none / basic / proficient)
-
-**none** -- Has not called an API directly. Uses tools with built-in integrations.
-
-- Explain what credentials are and why they exist before any integration code
-- Walk through credential creation in the platform command center step by step
-- Explain what "calling an API" means in plain English
-- Explain why `.env` exists and what `ELEVASIS_PLATFORM_KEY` is for
-- Do not assume they understand HTTP methods, JSON, or authentication headers
-
-**basic** -- Has used APIs with documentation or built simple integrations.
-
-- Show `platform.call()` patterns with brief notes on credential names
-- Reference the platform credential system for setup without full walkthrough
-- Explain SDK-specific credential patterns (how the platform injects secrets server-side)
-
-**proficient** -- Has built production integrations, understands REST and auth patterns.
-
-- Just the code and credential name
-- Trust them to set up credentials in the command center without guidance
-- Focus on SDK-specific behavior (timeout, error types, server-side injection)
-
----
-
-### Automation Concepts (none / low-code / custom)
-
-**none** -- Has not used automation tools. Thinks in manual processes.
-
-- Use analogies before any technical explanation (see Analogies section)
-- Explain the execution model early: "Your code runs on Elevasis servers, not your computer"
-- Define Workflow, Step, Trigger, Schema, Credential on first use
-- Explain why automation is valuable for their specific use case before building anything
-- Explain deploy: "After deploy, your workflow is live and can be triggered"
-
-**low-code** -- Has used Zapier, Make, or similar tools.
-
-- Map Elevasis concepts to tools they know: "Steps are like Zapier actions. The workflow is the Zap."
-- Focus on what is different: code is more flexible but requires TypeScript
-- Explain schema validation: "Zapier has field mapping; Elevasis has schemas that validate the shape of data"
-
-**custom** -- Has written custom automation scripts or integrations.
-
-- Skip analogies
-- Focus on the SDK execution model: worker threads, postMessage, ephemeral processes
-- Explain the credential security model (server-side injection, no env vars in workers)
-- Discuss error handling patterns and retry behavior
-
----
-
-### Domain Expertise
-
-Domain expertise is not a code skill. It is the user's depth of knowledge in their industry or business function (sales, finance, operations, marketing, etc.).
-
-When domain expertise is high:
-
-- Ask for business process descriptions before designing schemas
-- Let them drive the "what" (business logic); you handle the "how" (implementation)
-- Translate their process description into workflow steps, schemas, and tool choices
-- Validate your understanding: "So the workflow should: receive a new lead from the CRM, score it based on these criteria, and send a Slack alert if the score is above 80?"
-- Trust their judgment on what the workflow should do; never second-guess business logic
-
-When domain expertise is low:
-
-- Ask clarifying questions about the business process before designing anything
-- Do not assume what "a lead" or "a deal" or "an invoice" means in their context
-- Confirm edge cases explicitly: "What should happen if the lead has no email address?"
-
----
-
-## Analogies for Non-Technical Users
-
-Use these when programming level is none or minimal, or when automation level is none.
-
-| Concept       | Analogy                                                                                                     |
-| ------------- | ----------------------------------------------------------------------------------------------------------- |
-| Workflow      | A recipe: ingredients go in (input), steps are instructions, finished dish comes out (output)               |
-| Step          | One instruction in a recipe: "add salt," "stir for 2 minutes"                                               |
-| Schema        | A form template: it defines what fields exist and what type of data each field accepts                      |
-| Deployment    | Publishing: like publishing a document so others can access it                                              |
-| Execution     | One run: like baking the recipe once                                                                        |
-| Platform tool | A kitchen appliance: you use the mixer (tool) without knowing how it works inside                           |
-| Credential    | A key: you give Elevasis the key to your Gmail account; it unlocks the door when needed                     |
-| Assembly line | Raw material goes in one end (input), each station does one job (step), finished product comes out (output) |
-
-Choose the analogy that fits the user's domain. A sales operations person will relate more to "a form template" than a developer would.
-
----
-
-## Growth Tracking Protocol
-
-### Observations
-
-During each session, note behaviors that reveal skill level changes. Examples:
-
-- User wrote a handler without asking for help
-- User suggested using StepType.CONDITIONAL without prompting
-- User asked a question that shows they now understand the execution model
-- User navigated to the correct Command Center page without being directed
-- User filtered Execution Logs by resource independently to diagnose a failure
-- User created a Task Scheduler entry unassisted
-
-### Promotion Rules
-
-Do not automatically update the skill profile for every observation. Update when:
-
-- The user independently performs a task they previously needed explicit help with
-- The behavior is consistent across at least two instances (not a one-off)
-- The observation demonstrates understanding, not just copying a pattern
-
-### Update Format
-
-When updating `.claude/memory/profile/skills.md` Growth Log:
-
-```
-| Date | Observation | Dimension | Change |
-| 2026-03-01 | Navigated to Execution Logs and filtered by resource without direction | platformNavigation | none -> oriented |
-```
-
-Also update the dimension's Level and Since fields in the Dimensions table.
-
-### Celebration
-
-When growth is observed, acknowledge it briefly:
-
-- "You found that on your own -- looks like you've got the Command Center navigation down."
-- "Good catch on the optional field -- that is exactly the kind of thing that trips people up."
-
-Keep it natural. One sentence is enough. Do not over-celebrate.
-
----
-
-## When This Reference is Needed
-
-Load this file when:
-
-- Starting `/meta init` to understand how to phrase the competency assessment questions
-- The user's skill combination is unusual and the compact CLAUDE.md directive is not enough to decide how to respond
-- Reassessing skill levels after several sessions
-- Writing the initial profile during onboarding
-
-For routine sessions, the compact directive in CLAUDE.md plus the user's stored `skills.md` is sufficient.
-
----
-
-**Last Updated:** 2026-02-26

package/reference/sdk/framework/memory.mdx

@@ -1,326 +0,0 @@
----
-title: Memory System
-description: Cross-session project knowledge stored in .claude/memory/ -- deployment state, environment, decisions, and error patterns that persist between Claude Code sessions
-loadWhen: "Working with agent memory or session state"
----
-
-The memory system gives Claude Code a structured knowledge base for your project that survives across sessions. Deployment history, discovered credentials, architectural decisions, and error patterns are all written to `.claude/memory/` as the project evolves -- so the agent never starts from scratch.
-
-The `memory/` directory is gitignored and personal to each developer. The `profile/` subdirectory is created by `/meta init` during first-run setup. All other topics are created by the agent as the project evolves.
-
-## Purpose
-
-Without project memory, the agent starts every session with only the context of the current conversation. It cannot remember that you already deployed yesterday, that a particular credential is configured, or that you encountered and solved a specific TypeScript error last week.
-
-With project memory, the agent loads a root index at session start, sees what has been recorded, and can retrieve detail on demand. Error patterns are matched before diagnosis. Deployment state is available before deploying again. The agent can say "I've seen this before -- here's the fix" instead of repeating the same diagnostic process.
-
-## Architecture
-
-Memory is organized as a hierarchical index tree. Every directory has an `index.md` that maps to its children -- either content files or subdirectories with their own indexes.
-
-**The invariant:** A reader always starts at the root index and drills down. The agent reads `memory/index.md` at session start. It reads individual topic files on demand when the user asks about that topic or the agent is about to perform an action in that domain.
-
-**The scaling rule:** When a content file outgrows a single document, it graduates into a subdirectory:
-
-1. `topic.md` becomes `topic/index.md` + sub-files
-2. The parent index updates its link from `topic.md` to `topic/index.md`
-3. The new sub-index maps to the sub-files
-
-This pattern is recursive. Subdirectories can split further as needed. The agent applies its own judgment about when a file has grown past usefulness as a single document.
-
-### Starting Structure
-
-After `/meta init` and a first deployment, the structure looks like this:
-
-```
-.claude/memory/
-├── index.md                    # Root index -- read at session start
-├── profile/                    # Developer profile (created by /meta init)
-│   ├── index.md                # Profile summary with links to sub-files
-│   ├── identity.md             # Organization, industry, goals, integrations
-│   ├── skills.md               # Skill dimensions and Growth Log
-│   └── preferences.md          # Verbosity, guidance style, interaction patterns
-├── deployment-state.md         # Deploy IDs, resource inventory, org info
-├── environment.md              # Credentials, API keys, env vars
-├── decisions.md                # Architectural decisions and patterns
-└── errors/                     # Subdirectory -- multiple categories
-    ├── index.md                # Error category summary with counts
-    ├── deploy.md               # Deployment error patterns
-    ├── runtime.md              # Runtime execution error patterns
-    └── typescript.md           # Type and build error patterns
-```
-
-Profile tracking starts as a subdirectory because it has natural sub-topics from day one (identity, skills, preferences). Error tracking starts as a subdirectory because it naturally spans multiple categories. Other topics start as flat files.
-
-### Grown Structure
-
-As a project matures, other topics may split:
-
-```
-.claude/memory/
-├── index.md
-├── environment.md
-├── decisions.md
-├── deployment-state/           # Grew large enough to split
-│   ├── index.md
-│   ├── resources.md
-│   └── history.md
-└── errors/
-    ├── index.md
-    ├── deploy.md
-    ├── typescript.md
-    └── runtime/                # Runtime errors grew further
-        ├── index.md
-        ├── lead-scorer.md
-        └── email-sender.md
-```
-
-## Memory Topics
-
-### Developer Profile
-
-The `profile/` directory stores the developer's personal context -- organization details, skill levels, goals, and interaction preferences. It is created during `/meta init` guided setup and is the first thing the root index links to.
-
-```
-.claude/memory/profile/
-├── index.md          # Profile summary with links to sub-files
-├── identity.md       # Organization, industry, goals, integrations
-├── skills.md         # Skill dimensions and Growth Log
-└── preferences.md    # Verbosity, guidance style, interaction patterns
-```
-
-**`identity.md`** records the organization name, industry, size, project goals, and known tool integrations. Example:
-
-```markdown
-# Identity
-
-| Field | Value |
-| --- | --- |
-| Organization | Acme Corp |
-| Industry | E-commerce |
-| Size | 10-50 |
-
-## Project Goals
-
-- Automate lead scoring from Attio CRM
-- Send follow-up emails via Resend
-- Weekly pipeline reports
-
-## Known Integrations
-
-- Attio (CRM)
-- Resend (email)
-- Google Sheets (reporting)
-```
-
-**`skills.md`** stores four skill dimensions as structured values so the Adaptive Guidance rules in [Interaction Guidance](interaction-guidance.mdx) can apply them consistently. It also tracks a Growth Log so the agent can detect when a level upgrade is warranted. Example:
-
-```markdown
-# Skills
-
-| Dimension | Level | Since |
-| --- | --- | --- |
-| platformNavigation | oriented | 2026-02-25 |
-| apiIntegration | basic | 2026-02-25 |
-| automation | low-code | 2026-02-25 |
-| domainExpertise | high | 2026-02-25 |
-
-## Growth Log
-
-| Date | Observation | Dimension | Change |
-| --- | --- | --- | --- |
-| 2026-03-01 | Navigated to Execution Logs and filtered by resource without direction | platformNavigation | none -> oriented |
-```
-
-Valid levels per dimension:
-
-- `platformNavigation`: none / oriented / comfortable
-- `apiIntegration`: none / basic / proficient
-- `automation`: none / low-code / custom
-- `domainExpertise`: high / low
-
-**`preferences.md`** stores verbosity and proactive guidance settings. Example:
-
-```markdown
-# Preferences
-
-| Setting | Value |
-| --- | --- |
-| Verbosity | detailed |
-| Proactive guidance | yes |
-```
-
-### Root Index
-
-`memory/index.md` is the only file read at session start. It lists all topics with their last-updated dates, giving the agent enough context to know what has been recorded without loading any detail.
-
-```markdown
-# Project Memory
-
-Agent-maintained cross-session knowledge base. Updated automatically.
-
-| Entry | Topic | Last Updated |
-| --- | --- | --- |
-| [profile/](profile/index.md) | Developer profile (skills, identity, preferences) | 2026-02-25 |
-| [deployment-state.md](deployment-state.md) | Deploy history, resource inventory, org info | 2026-02-25 |
-| [environment.md](environment.md) | Credentials, API keys, env vars | 2026-02-25 |
-| [decisions.md](decisions.md) | Architectural decisions and patterns | 2026-02-26 |
-| [errors/](errors/index.md) | Error patterns by category | 2026-02-26 |
-```
-
-Subdirectory entries link to their `index.md` rather than the directory itself.
-
-### Deployment State
-
-`deployment-state.md` tracks the most recent deploy and resource inventory. The agent updates it after every successful deployment.
-
-```markdown
-# Deployment State
-
-## Latest Deploy
-
-| Field | Value |
-| --- | --- |
-| Date | 2026-02-26 |
-| Deploy ID | dep_abc123 |
-| Resource count | 2 |
-| Organization | acme-corp |
-
-## Resources
-
-- `echo` (workflow, dev) -- echoes input, starter resource
-- `lead-scorer` (workflow, prod) -- scores leads from Attio
-
-## Deploy History
-
-| Date | Deploy ID | Resources | Status |
-| --- | --- | --- | --- |
-| 2026-02-26 | dep_abc123 | 2 | success |
-| 2026-02-25 | dep_xyz789 | 1 | success |
-```
-
-### Environment
-
-`environment.md` records discovered credentials and environment variable status. The agent updates it when credentials are confirmed via the command center or deployment output.
-
-### Decisions
-
-`decisions.md` captures architectural choices as a table: which tools were chosen, what patterns were established, and why. The agent adds a row when the user makes a significant decision during development.
-
-## Error Tracking
-
-Error tracking is the first memory topic to outgrow a flat file. It starts as a subdirectory with one file per error category.
-
-### Error Index
-
-`errors/index.md` provides a high-level summary of known error patterns by category. The agent reads this file (via the root index) at session start.
-
-```markdown
-# Error Patterns
-
-Error pattern tracking by category. Updated when errors are diagnosed and resolved.
-
-| Entry | Category | Patterns | Total Occurrences | Last Seen |
-| --- | --- | --- | --- | --- |
-| [deploy.md](deploy.md) | Deployment | 2 | 3 | 2026-02-26 |
-| [runtime.md](runtime.md) | Runtime | 1 | 1 | 2026-02-26 |
-| [typescript.md](typescript.md) | TypeScript | 1 | 2 | 2026-02-25 |
-```
-
-- **Patterns** -- count of unique error patterns in the category file
-- **Total Occurrences** -- sum of all occurrences across patterns
-- **Last Seen** -- most recent date any error in this category was seen
-
-### Category Files
-
-Each category file is a table of known error patterns with resolutions:
-
-```markdown
-# Deploy Errors
-
-| Last Seen | Error | Resolution | Occurrences |
-| --- | --- | --- | --- |
-| 2026-02-25 | `ELEVASIS_PLATFORM_KEY not set` | Added key to `.env` | 2 |
-| 2026-02-26 | `Schema validation: missing outputSchema` | Added Zod output schema to workflow | 1 |
-```
-
-Runtime errors include the resource name since the same error in different resources may have different causes:
-
-```markdown
-# Runtime Errors
-
-| Last Seen | Resource | Error | Resolution | Occurrences |
-| --- | --- | --- | --- | --- |
-| 2026-02-26 | lead-scorer | `PlatformToolError: credential not found` | Set credential via `elevasis-sdk env set` | 1 |
-```
-
-### Error Resolution Flow
-
-When the agent encounters an error, it follows this sequence:
-
-1. Checks `memory/errors/index.md` (already loaded via root index) for a matching category
-2. If the relevant category has known patterns, reads the category file
-3. If a match exists, applies the known resolution immediately -- "I've seen this before, here's the fix"
-4. If no match exists, diagnoses normally, then logs the new pattern
-
-When the agent logs a resolved error:
-
-1. Reads the relevant category file (e.g., `memory/errors/deploy.md`)
-2. If the pattern already exists, increments `Occurrences` and updates `Last Seen`
-3. If it is a new pattern, adds a new row
-4. Updates the error index: recalculates `Patterns`, `Total Occurrences`, and `Last Seen`
-5. If the category file does not exist yet, creates it and adds a row to the error index
-
-## Scaling Rule
-
-When a file has grown past usefulness as a single document -- too many rows to scan, too many unrelated concerns, or too much context to load for a targeted lookup -- split it into a subdirectory.
-
-**Before split:**
-
-```
-memory/
-├── index.md
-└── deployment-state.md         # entry: deployment-state.md
-```
-
-**After split:**
-
-```
-memory/
-├── index.md                    # entry updated: deployment-state/ -> deployment-state/index.md
-└── deployment-state/
-    ├── index.md
-    ├── resources.md
-    └── history.md
-```
-
-The parent index link changes from `deployment-state.md` to `deployment-state/index.md`. The new sub-index maps to the sub-files. The agent applies this pattern at every depth level.
-
-## Maintenance
-
-### Pruning
-
-Keep content useful, not exhaustive:
-
-- Keep the most recent ~20 entries in tables that grow over time (deploy history, error patterns)
-- Drop patterns that have not recurred in 30 or more days unless the resolution was non-obvious
-- Summarize if patterns are worth preserving but detail is not
-
-### Index Hygiene
-
-- If a file exists but is not in its parent index, add it
-- If an index references a missing file, remove the row
-
-The agent self-heals on read. Index hygiene is applied as part of normal session operation.
-
-### Promotion
-
-If an error pattern recurs 3 or more times, promote it to a rule in the `CLAUDE.md` Rules section. Rules prevent errors rather than diagnosing them.
-
-## Relationship to Claude Code Auto-Memory
-
-Claude Code's auto-memory (`MEMORY.md`) and project memory (`.claude/memory/`) are complementary -- both should be active. Auto-memory captures organic discoveries; project memory captures structured project state that `CLAUDE.md` explicitly instructs the agent to record.
-
----
-
-**Last Updated:** 2026-02-25