@coreyuan/vector-mind 1.0.53 → 1.1.0

package/skills/vector-mind-autopilot/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: vector-mind-autopilot
-description: "Automatically apply the VectorMind MCP workflow for local requirement-driven memory. Always pass project_root in every VectorMind tool call: bootstrap_context on session start, start_requirement and preflight_change_scope before edits, sync_change_intent after edits, and semantic_search/query_codebase instead of guessing."
+description: "Apply a bounded VectorMind MCP workflow for local requirement-driven memory. Always pass project_root, restore focused context once per project goal, start/preflight once per requirement, and sync once after edits without routing every read through MCP."
 ---
 
 # VectorMind Autopilot
@@ -32,22 +32,38 @@ Why: some clients start MCP servers from unrelated folders. Passing `project_roo
 3. If needed, walk upward to a marker like `.git`, `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, or `*.sln`.
 4. Validate once with `bootstrap_context({ project_root, query })`; prefer `root_source: "tool_arg"` and a `db_path` under `<project>/.vectormind/`.
 
-## Required call chain
+## Bounded lifecycle
 
 For development, debugging, refactoring, design, or code-change tasks:
 
+### Activation contract
+
+- Seeing this skill in the available-skill list is not enough. When VectorMind tools are available and historical context can help, use the focused bootstrap once before broad repository exploration.
+- If VectorMind tools are unavailable, make at most one bounded discovery attempt, then continue with native tools. Do not repeatedly search for or reconnect the MCP server inside the task.
+- Pure execution with explicit targets may skip bootstrap.
+
+Normal work should use no more than four VectorMind workflow calls:
+
+1. one focused bootstrap when historical context is needed;
+2. one requirement start for a genuinely new requirement;
+3. one preflight for the complete planned file set;
+4. one final change-intent sync.
+
+Do not repeat lifecycle calls after every compaction, tool error, validation step, build, retry, or follow-up.
+
 ### 1. Start / resume
 
-Call:
+Call at most once per project goal:
 
 ```text
-bootstrap_context({ project_root, query, top_k: 5, pending_limit: 50, requirements_limit: 3, changes_limit: 5, notes_limit: 5, current_context_limit: 8, preview_chars: 200 })
+bootstrap_context({ project_root, query, top_k: 3, context_mode: "focused", max_output_chars: 6000 })
 ```
 
-Use returned summaries, decisions, current context, notes, pending changes, and matches to ground the plan.
+Use the project summary, active requirement anchor, and query-relevant matches to ground the plan. Default focused mode intentionally omits completed recent-history anchors, pending files, and broad constraints because they frequently distract from the current goal. If no memory passes focused relevance filtering, continue from current repository facts instead of using an unrelated fallback.
+Use `include_recent=true` or `context_mode="full"` only when the task explicitly requires recent cross-turn history. Use `include_pending=true` only for scope diagnosis; normal completion should call `get_pending_changes` directly if needed.
 If `quality_signals.relevant_fix_patterns` appears, treat it as a historical regression reminder only. Do not let it expand the current requirement, change `ok`/`safe_to_edit`, or override direct repository facts.
 
-Skip this only for pure execution-first tasks with explicit targets, such as a known build/test/package command.
+Skip bootstrap for pure execution-first tasks with explicit targets, and when the current project goal has already been bootstrapped in this conversation.
 
 For concrete operation commands where stale defaults could matter (deploy/publish/build/test/migrate/service/git/batch scripts), call:
 
@@ -55,28 +71,34 @@ For concrete operation commands where stale defaults could matter (deploy/publis
 preflight_operation_scope({ project_root, operation, intent, commands?, files?, targets?, script_hints? })
 ```
 
+Call it immediately before the first concrete operation command. Do not run an exploratory `git status`, deployment inspection, publish command, build, or test first and preflight afterward; include those first commands in the single planned command set.
+
 Treat `stale_default_conflict` or `operation_constraint_conflict` as advisory quality signals: align the plan with current constraints, directly observed repo facts, or explicit user instructions before running commands.
 
 ### 2. Before editing
 
-Call:
+Call once for a new user requirement:
 
 ```text
 start_requirement({ project_root, title, background })
 ```
 
+Keep the returned `requirement.id` or a caller-provided `goal_key`. Pass `req_id` or `goal_key` to preflight and sync whenever multiple tasks, agents, or sessions may overlap in the same project.
+
+Continue using the active requirement for follow-ups, builds, verification, and retries. Exact duplicate starts are reused by the server, but clients should still avoid unnecessary calls.
 For narrow tasks, pass `scope_allow`, `scope_deny`, `allowed_paths`, or `denied_paths` when useful.
 If the user request has clear bullets, acceptance points, or numbered items, also pass `requirement_items` so later edits can be checked against the actual request.
 
-Once planned files/modules are known, call:
+Once the complete planned file/module set is known, call once:
 
 ```text
-preflight_change_scope({ project_root, intent, files })
+preflight_change_scope({ project_root, req_id?, goal_key?, intent, files })
 ```
 
 For explicit requirements, pass `planned_changes` with `requirement_refs`. Mark purely mechanical/test/build/formatting support as `supporting_change=true`.
 
-Treat `safe_to_edit=false` as a pre-edit scope warning for file changes, not a reasoning override. Do not edit the warned files until you narrow the files/scope, verify the warning is stale, or the user explicitly expands the requirement.
+Treat ordinary `safe_to_edit=false` scope findings as pre-edit warnings, not reasoning overrides. A `workflow_gate.code="huge_file_modularization_required"` result is the bounded exception: stop normal feature editing for that file and follow the mechanical modularization workflow. The MCP still does not control host execution.
+Repeat preflight only if the planned scope materially changes.
 
 If a tool output includes `project_context_advisory` / `cross_project_reference`, treat that project as a separate context. If the current requirement belongs to another `project_root`, use the switched project only as read-only external evidence unless the user explicitly changes the target project.
 
@@ -84,22 +106,42 @@ If a tool output includes `project_context_advisory` / `cross_project_reference`
 
 If any VectorMind tool returns `huge_file_modularization_required`:
 
-1. Stop normal feature work.
-2. Call `plan_large_file_split({ project_root, file })`.
-3. Perform mechanical modularization with real module names/directories.
-4. Never create `*.generated.*`, `.parts`, `*.rs.parts`, or `part1/part2` fake split files.
-5. Call `record_large_file_split(...)`.
+1. Stop normal feature editing for that file.
+2. Call `plan_large_file_split({ project_root, req_id?, goal_key?, file })`, passing the selected requirement identity when tasks may overlap. Preserve the returned `plan_id`; the plan is persisted with declaration coverage, a true source-content SHA-256, and a fingerprint of the effective planning boundaries.
+3. If heuristic planning returns `needs_refinement`, call `plan_large_file_split` again with semantic `module_overrides` using declaration names or line ranges. Overrides must assign every detected declaration exactly once, stay under the target directory, and satisfy the fixed safety ceilings. The refined plan supersedes the failed plan; do not record progress against `needs_refinement`.
+4. Rerun preflight with `change_mode="mechanical_modularization"` and `split_plan_id` (or `split_plan_ids` for multiple huge files). Only a complete plan whose source state still matches satisfies the gate.
+5. Perform mechanical modularization with real module names/directories. Keep the split attached to the current requirement; do not start a second requirement unless parent/child lifecycle is explicitly supported.
+6. Never create `*.generated.*`, `.parts`, `*.rs.parts`, or `part1/part2` fake split files.
+7. Use `record_large_file_split({ project_root, req_id?, goal_key?, plan_id, ... })` to update the same persisted plan when work is in progress, partial, or resolved. Status transitions are monotonic (`planned -> in_progress|partial|resolved`, `in_progress -> partial|resolved`, `partial -> in_progress|resolved`); submitted module paths must exist. Resolved status requires real module paths, a reduced source file, verification evidence, and no verification gaps.
+
+A minimal bugfix may use `change_mode="bugfix"` with `adds_responsibility=false` and a concrete `defer_split_reason` without first expanding the task into a full split plan. This channel must not add new responsibilities. Include `large_file_split_deferrals: [{ file, reason }]` in the final `sync_change_intent` so the debt remains durable; each deferred file must be part of that sync and must still be huge or have an unfinished split plan. `emergency_hotfix` uses the same durable deferral record and is reserved for urgent minimal fixes. Completing a requirement automatically marks any unfinished split plans `deferred` so stale plans do not remain active context.
 
 ### 4. After editing
 
-Call:
+Call once after editing:
 
 ```text
-get_pending_changes({ project_root })
-sync_change_intent({ project_root, intent, files? })
+sync_change_intent({ project_root, req_id?, goal_key?, intent, files })
 ```
 
-The intent should say what changed, why, and any follow-up.
+The intent should say what changed, why, and any follow-up. Include `large_file_split_deferrals` when a minimal bugfix or emergency hotfix deferred a huge-file split. Call `get_pending_changes({ project_root })` first only when the changed file list is unknown or an explicit scope audit is needed.
+
+If later verification produces stronger evidence after a requirement was completed, do not reopen it only to rewrite history. Update the latest linked change intent with:
+
+```text
+update_requirement_verification({
+  project_root,
+  req_id?,
+  goal_key?,
+  verification?,
+  verification_gaps?,
+  resolved_verification_gaps?,
+  replace_verification?,
+  replace_verification_gaps?
+})
+```
+
+The tool accepts active or completed requirements, rejects superseded requirements, and writes a linked `verification_update` audit record. Verification entries merge by default; verification gaps are authoritative replacement data by default so a later passing test run can clear stale gaps.
 
 If the edit fixed a known recurring class of defect and the root cause is clear, you may include `fix_pattern` in `sync_change_intent`:
 
@@ -135,10 +177,10 @@ For durable context:
 
 ## Code search and reading
 
-- Use `query_codebase({ project_root, query })` for symbol/code location.
-- Use `grep({ project_root, query })` for exact text matches.
-- Use `read_file_lines(...)` or `read_file_text(...)` for bounded reads.
-- Use `semantic_search(...)` for prior requirements, decisions, notes, code chunks, and docs.
+- Use `query_codebase({ project_root, query })` when symbol/code location is unknown.
+- Use `semantic_search(...)` for historical requirements, decisions, notes, code chunks, and docs.
+- Native bounded `rg`, `git`, and host file tools are valid for known paths and exact repository reads. Do not route every search or file read through VectorMind.
+- Batch related reads/searches instead of creating one model round trip per file or pattern.
 - Use `memory_timeline(...)` to understand the order of related requirements, decisions, notes, and changes.
 - Use `read_memory_item(...)` for full text only when needed.
 
@@ -157,6 +199,23 @@ For low-risk diagnosis, use `memory_quality_report(...)`, `analyze_memory_confli
 - Summarize active requirement, key warnings, changed files, validation, and next step.
 - VectorMind defines development memory and quality workflow only. It does not manage client runtime controls.
 
+## Host output budget
+
+- Keep a normal standalone command at or below 4000 output tokens.
+- Run at most 4 commands in parallel, each at most 4000, with the batch's combined requested budget at or below 12000.
+- A failing diagnostic that cannot be narrowed may run alone with up to 12000. Use up to 20000 only when the user explicitly asks for raw output; never request routine 30000/40000 outputs.
+- After 12 shell commands in one user turn, synthesize and stop broad exploration. Do not exceed 24 host commands in one user turn, excluding polls.
+- Exclude dependency, generated, cache, and build trees from recursive discovery, including `node_modules`, `target`, `dist`, `build`, `bin`, `obj`, and `.git`.
+- Locate first, then read bounded ranges of about 250 lines from large implementation files.
+- If one result exceeds 8000 tokens, narrow or paginate the next read and do not follow it with another broad result.
+
+## RTK policy
+
+- Detect RTK at most once per session.
+- Use RTK only for supported external CLIs when summarized output is acceptable.
+- Never prefix PowerShell cmdlets such as `Get-Content`, `Get-ChildItem`, `Select-Object`, or `Test-Path` directly.
+- Use `rtk proxy` for exact logs, JSON, failing diagnostics, or a PowerShell command host.
+
 ## Troubleshooting
 
 - Skills are loaded when the client starts. Restart the client after installing/updating this skill.

package/skills/vector-mind-autopilot/references/claude-project-instructions.md

@@ -6,31 +6,32 @@ Use VectorMind as evidence and workflow guardrails, not as a replacement for mod
 
 Always pass `project_root` on every VectorMind tool call.
 
+Seeing VectorMind in the available tool list is not enough. When its tools are available and historical context can help, call the focused bootstrap once before broad repository exploration. If tools are unavailable, make at most one bounded discovery attempt and continue with native tools. Pure execution with explicit targets may skip bootstrap.
+
 ## Required workflow
 
 1. At the start of a new chat or when resuming:
-   - Call `bootstrap_context({ project_root, query, top_k: 5, pending_limit: 50, requirements_limit: 3, changes_limit: 5, notes_limit: 5, current_context_limit: 8, preview_chars: 200 })`.
-   - Use returned `current_constraints` as compact evidence of current decisions/conventions/active requirements.
+   - Call `bootstrap_context({ project_root, query, top_k: 3, context_mode: "focused", max_output_chars: 6000 })` at most once per project goal when historical context is needed.
+   - Use returned `current_constraints` and the active requirement anchor as compact evidence. If no memory passes focused filtering, continue from repository facts instead of using an unrelated fallback.
    - Treat `quality_signals.relevant_fix_patterns` as advisory regression reminders only; they must not expand the current requirement or change `ok` / `safe_to_edit`.
    - Before concrete operation commands where stale defaults could matter, call `preflight_operation_scope({ project_root, operation, intent, commands?, files?, targets?, script_hints? })`. Treat conflicts as advisory quality signals, not host-execution control.
 
 2. Before editing:
-   - Call `start_requirement({ project_root, title, background })`.
+   - Call `start_requirement({ project_root, title, background })` once for a genuinely new requirement; preserve its `requirement.id` or `goal_key` and pass `req_id` or `goal_key` to later lifecycle calls when tasks may overlap. Reuse the active requirement for follow-ups, builds, retries, and validation.
    - If the request has clear bullets, acceptance points, or numbered items, pass `requirement_items`.
-   - Then call `preflight_change_scope({ project_root, intent, files })` once target files/modules are known.
+   - Then call `preflight_change_scope({ project_root, req_id?, goal_key?, intent, files })` once target files/modules are known.
    - For explicit requirements, pass `planned_changes` with `requirement_refs`; mark purely mechanical/test/build/formatting support as `supporting_change=true`.
-   - Treat `safe_to_edit=false` as a pre-edit scope warning for file changes, not a reasoning override. Do not edit the warned files until you narrow the files/scope, verify the warning is stale, or the user explicitly expands the requirement.
+   - Treat ordinary `safe_to_edit=false` findings as pre-edit scope warnings, not reasoning overrides. `workflow_gate.code="huge_file_modularization_required"` is the bounded exception requiring mechanical modularization before normal feature editing continues.
    - If a tool output includes `project_context_advisory` / `cross_project_reference`, treat that project as separate context. If the current requirement belongs to another `project_root`, use the switched project only as read-only external evidence unless the user explicitly changes the target project.
 
 3. If a huge-file warning appears:
-   - Call `plan_large_file_split({ project_root, file })`.
-   - Do mechanical modularization with real module names/directories.
+   - Call `plan_large_file_split({ project_root, req_id?, goal_key?, file })`, preserve its persisted `plan_id`, and rerun preflight with `change_mode="mechanical_modularization"` plus `split_plan_id`/`split_plan_ids`.
+   - Do mechanical modularization with real module names/directories while keeping it attached to the current requirement.
    - Never create generated/parts/partN fake split files.
-   - Call `record_large_file_split(...)`.
+   - Call `record_large_file_split({ project_root, req_id?, goal_key?, plan_id, ... })` to update the same plan. Resolved status requires real module paths, reduced source/module lines, verification evidence, and no gaps. Minimal bugfixes may defer planning only with `adds_responsibility=false` and `defer_split_reason`, persisted through final `sync_change_intent.large_file_split_deferrals`.
 
 4. After editing:
-   - Call `get_pending_changes({ project_root })`.
-   - Call `sync_change_intent({ project_root, intent, files? })`.
+   - Call `sync_change_intent({ project_root, req_id?, goal_key?, intent, files })` once. Use `get_pending_changes({ project_root })` only when the changed file set is unknown or scope drift must be diagnosed.
    - If a known recurring defect class was fixed and the root cause is clear, optionally include a generic `fix_pattern`; VectorMind does not infer fix patterns automatically.
 
 5. If newer decisions override older behavior:
@@ -42,7 +43,9 @@ Always pass `project_root` on every VectorMind tool call.
    - Call `complete_requirement(...)` when done.
    - Use `analyze_memory_conflicts(...)`, `memory_quality_report(...)`, or `compare_checkpoint_context(...)` only when auditing memory quality, stale-rule regressions, or checkpoint drift.
 
-Use `query_codebase`, `grep`, `read_file_lines`, `semantic_search`, and `memory_timeline` instead of guessing.
+Use `query_codebase`, `semantic_search`, and `memory_timeline` when historical or unknown-location evidence is needed. For known paths and exact repository reads, native bounded search/file tools are valid; batch related reads instead of routing every file through MCP.
+
+Keep a normal standalone command at or below 4000 output tokens. A parallel batch may contain at most 4 commands, each at most 4000, with a combined requested budget at or below 12000. A failing diagnostic that cannot be narrowed may run alone with up to 12000; use 20000 only when the user explicitly requests raw output. After 12 shell commands in one user turn, synthesize and stop broad exploration; do not exceed 24 commands excluding polls. Exclude dependency/generated/cache/build trees from recursive discovery. Locate first, then read bounded ranges of about 250 lines. If one result exceeds 8000 tokens, narrow or paginate the next read.
 
 Do not dump raw JSON unless asked.
 

package/skills/vector-mind-autopilot/references/universal-system-prompt.md

@@ -14,35 +14,37 @@ Always pass `project_root` on every VectorMind tool call.
 
 Do not rely on the MCP server process working directory. Some clients start MCP servers from unrelated folders.
 
-## Required development call chain
+## Bounded development lifecycle
 
-For code/design/debug/refactor tasks, follow this chain:
+For code/design/debug/refactor tasks, target no more than four workflow calls: one focused bootstrap, one requirement start, one preflight, and one final sync. Do not repeat lifecycle calls for compaction, retries, builds, verification, or follow-ups under the same active requirement.
+
+Seeing VectorMind in a tool or skill list is not enough: when its tools are available and historical context can help, call the focused bootstrap once before broad exploration. If tools are unavailable, make at most one bounded discovery attempt and continue with native tools. Pure execution with explicit targets may skip bootstrap.
 
 1. **Start/resume**
-   - Call `bootstrap_context({ project_root, query, top_k: 5, pending_limit: 50, requirements_limit: 3, changes_limit: 5, notes_limit: 5, current_context_limit: 8, preview_chars: 200 })`.
-   - Use `project_summary`, `decisions`, `current_constraints`, `current_context`, `recent_notes`, `pending_changes`, and matches to ground the plan.
+   - Call `bootstrap_context({ project_root, query, top_k: 3, context_mode: "focused", max_output_chars: 6000 })` at most once per project goal when historical context is needed.
+   - Use the project summary, active requirement anchor, and query-relevant matches to ground the plan. Focused mode deliberately omits completed broad recency and pending state; no relevant match is better than an unrelated fallback.
+   - Use `include_recent=true` or `context_mode="full"` only when recent cross-turn history is required. Use `include_pending=true` only for scope diagnosis.
    - Treat `quality_signals.relevant_fix_patterns` as advisory regression reminders only; they must not expand the current requirement or change `ok` / `safe_to_edit`.
    - Before concrete operation commands where stale defaults could matter, call `preflight_operation_scope({ project_root, operation, intent, commands?, files?, targets?, script_hints? })`. Treat `stale_default_conflict` or `operation_constraint_conflict` as advisory quality signals, not host-execution control.
 
 2. **Before editing**
-   - Call `start_requirement({ project_root, title, background })`.
+   - Call `start_requirement({ project_root, title, background })` once for a genuinely new requirement. Preserve the returned `requirement.id` or caller-provided `goal_key`; pass `req_id` or `goal_key` to later lifecycle calls whenever tasks may overlap. Continue the active requirement for follow-ups, retries, builds, and validation.
    - For narrow work, pass `scope_allow`, `scope_deny`, `allowed_paths`, or `denied_paths` when useful.
    - If the user request has clear bullets, acceptance points, or numbered items, pass `requirement_items`.
-   - Once target files/modules are known, call `preflight_change_scope({ project_root, intent, files })`.
+   - Once the complete target file/module set is known, call `preflight_change_scope({ project_root, req_id?, goal_key?, intent, files })` once. Repeat only if scope materially changes.
    - For explicit requirements, pass `planned_changes` with `requirement_refs`; mark purely mechanical/test/build/formatting support as `supporting_change=true`.
-   - Treat `safe_to_edit=false` as a pre-edit scope warning for file changes, not a reasoning override. Do not edit the warned files until you narrow the files/scope, verify the warning is stale, or the user explicitly expands the requirement.
+   - Treat ordinary `safe_to_edit=false` findings as pre-edit scope warnings, not reasoning overrides. `workflow_gate.code="huge_file_modularization_required"` is the bounded exception: stop normal feature editing for that file and follow the mechanical modularization workflow.
    - If a tool output includes `project_context_advisory` / `cross_project_reference`, treat that project as separate context. If the current requirement belongs to another `project_root`, use the switched project only as read-only external evidence unless the user explicitly changes the target project.
 
 3. **Huge files**
-   - If any tool returns `huge_file_modularization_required`, stop normal feature work.
-   - Call `plan_large_file_split({ project_root, file })`.
-   - Perform mechanical modularization with real module names/directories.
+   - If a tool returns `huge_file_modularization_required`, stop normal feature editing for that file.
+   - Call `plan_large_file_split({ project_root, req_id?, goal_key?, file })`, preserve its persisted `plan_id`, and rerun preflight with `change_mode="mechanical_modularization"` plus `split_plan_id`/`split_plan_ids`. Keep the split attached to the current requirement.
    - Never create `*.generated.*`, `.parts`, `*.rs.parts`, or `part1/part2` fake split files.
-   - Call `record_large_file_split(...)` after planning or completing the split.
+   - Call `record_large_file_split({ project_root, req_id?, goal_key?, plan_id, ... })` to update that same plan. Resolved status requires real module paths, reduced source/module lines, verification evidence, and no gaps. A minimal `bugfix` may proceed without a full plan only with `adds_responsibility=false` and `defer_split_reason`; persist it in final `sync_change_intent.large_file_split_deferrals`. Emergency hotfixes use the same durable deferral record.
 
 4. **After editing**
-   - Call `get_pending_changes({ project_root })`.
-   - Call `sync_change_intent({ project_root, intent, files? })` with what changed and why.
+   - Call `sync_change_intent({ project_root, req_id?, goal_key?, intent, files })` once with what changed and why.
+   - Call `get_pending_changes({ project_root })` first only when the changed file list is unknown or scope drift must be diagnosed.
    - If a known recurring defect class was fixed and the root cause is clear, optionally include a generic `fix_pattern` with `symptom`, `root_cause`, `invariant`, `applies_when`, and `avoid_regression`. VectorMind does not infer fix patterns automatically.
 
 5. **Decision changes**
@@ -58,9 +60,9 @@ For code/design/debug/refactor tasks, follow this chain:
 
 ## Search and reading
 
-- Use `query_codebase({ project_root, query })` to locate symbols instead of guessing files.
-- Use `grep({ project_root, query })` for exact file/line matches.
-- Use `read_file_lines(...)` or `read_file_text(...)` for bounded file reads.
+- Use `query_codebase({ project_root, query })` when symbol location is unknown.
+- Native bounded `rg`, `git`, and host file tools are valid for known paths and exact repository reads; do not route every read through MCP.
+- Batch related searches and reads to reduce model round trips.
 - Use `semantic_search(...)` for prior requirements, decisions, notes, code chunks, and docs.
 - Use `memory_timeline(...)` to inspect what happened before/after related context.
 - Use `read_memory_item(...)` for full text only when needed.
@@ -78,4 +80,10 @@ For low-risk diagnosis, use `memory_quality_report(...)`, `analyze_memory_confli
 
 Do not dump raw JSON unless the user asks. Summarize the useful facts.
 
+Keep a normal standalone command at or below 4000 output tokens. A parallel batch may contain at most 4 commands, each at most 4000, with a combined requested budget at or below 12000. A failing diagnostic that cannot be narrowed may run alone with up to 12000; use 20000 only when the user explicitly requests raw output. After 12 shell commands in one user turn, synthesize and stop broad exploration; do not exceed 24 commands excluding polls. Exclude dependency/generated/cache/build trees from recursive discovery. Locate first, then read bounded ranges of about 250 lines. If one result exceeds 8000 tokens, narrow or paginate the next read.
+
 VectorMind only defines development memory and quality workflow. It does not manage client runtime controls. For long sessions, use `create_checkpoint(...)` and read back with `restore_checkpoint_context(...)`; restoring is read-only context, not a decision override.
+
+## RTK
+
+Detect RTK at most once. Use it selectively for supported external CLIs when summarized output is acceptable. Never prefix PowerShell cmdlets directly; use `rtk proxy` for exact logs, JSON, failing diagnostics, or a PowerShell command host.