create-snipara 2.0.4 → 2.0.5

package/dist/index.js

@@ -13,7 +13,7 @@ import { homedir } from "os";
 // package.json
 var package_default = {
   name: "create-snipara",
-  version: "2.0.4",
+  version: "2.0.5",
   description: "Onboard Snipara Hosted MCP Context + Memory with auth, companion workflows, and optional Snipara Sandbox",
   main: "dist/index.js",
   type: "module",
@@ -1758,7 +1758,9 @@ Agent task lifecycle:
 1. Start every new thread by validating hosted MCP availability, then use
    project-scoped \`snipara_recall\` and a targeted \`snipara_context_query\` before
    falling back to local documentation search.
-2. Use \`snipara_context_query\` for docs, business context, client/project truth, architecture notes, runbooks, and narrative source material.
+2. Use \`snipara_context_query\` for docs, business context, client/project truth,
+   architecture notes, runbooks, and narrative source material. Keep simple Q&A
+   and single-source lookups on a targeted \`snipara_context_query\`.
 3. When \`snipara_context_query\` returns \`answer_pack\`, treat it as the first-pass response plan: use its source facts, caveats, source map, and verification checklist before drafting claims.
 4. Use \`snipara_get_chunk\` to load cited source sections returned by reference-based queries before relying on precise wording.
 5. For coding tasks, choose a workflow mode before editing: LITE for small
@@ -1771,8 +1773,11 @@ Agent task lifecycle:
    context and \`snipara-companion code impact\` before risky multi-file changes, PR
    reviews, routes, services, jobs, auth, billing, deployment, schema, migrations,
    or explicit "what is missing" assessments.
-8. Use \`snipara_plan\` for complex work in any plan when exposed; reserve
-   \`snipara_decompose\` for FULL-mode work when the hosted server exposes it.
+8. Use \`snipara_plan\` for complex or multi-surface work in any plan when
+   exposed. For FULL-mode audits, comparisons, roadmap/implementation planning,
+   release readiness, or package-surface reviews, use \`snipara_decompose\` to
+   preserve the work axes and \`snipara_multi_query\` to execute independent
+   follow-up questions when Pro+ tools are exposed.
 9. When the LLM has produced a visible multi-phase plan and \`snipara-companion\`
    is installed, keep the machine plan in JSON and run
    \`snipara-companion workflow start --goal "<goal>" --plan-file <plan_json_file>\`.
@@ -1828,7 +1833,7 @@ ${EXPERIENCE_GOAL_SECTION}
 - Use \`snipara_context_query\` for source truth and \`snipara_get_chunk\` for exact cited sections.
 - When \`snipara_context_query\` returns \`answer_pack\`, use its facts, caveats, source map, and verification checklist before drafting claims.
 - For coding tasks, choose a workflow mode before editing: LITE for small single-phase changes, FULL managed workflow for multi-file, risky, release/deploy, architectural, compaction-prone, or future-maintainer-sensitive work.
-- Use \`snipara_plan\` for complex work when exposed; reserve \`snipara_decompose\` for FULL-mode work when the hosted server exposes it.
+- Use \`snipara_plan\` for complex or multi-surface work when exposed. Keep simple Q&A on targeted \`snipara_context_query\`; for FULL-mode audits, comparisons, roadmap/implementation planning, release readiness, or package-surface reviews, use \`snipara_decompose\` to preserve axes and \`snipara_multi_query\` for independent follow-up questions when Pro+ tools are exposed.
 - Use \`snipara_code_callers\`, \`snipara_code_imports\`, \`snipara_code_neighbors\`, or \`snipara_code_shortest_path\` for canonical structural code questions.
 - For code impact and structural code questions, use \`snipara-companion code callers/imports/neighbors/shortest-path/impact\` first when \`snipara-companion\` is installed; it auto-selects hosted MCP for clean indexed code or the local overlay for dirty/ahead worktrees and reports \`sourceSelection\`. Use hosted \`snipara_code_impact\` only when companion is unavailable or after push/reindex for canonical graph impact.
 - Run \`snipara-companion code impact\` before risky multi-file changes, PR reviews, routes, services, jobs, auth, billing, deployment, schema, migrations, or explicit "what is missing" assessments.
@@ -1874,7 +1879,7 @@ ${EXPERIENCE_GOAL_SECTION}
 - Run \`snipara-companion code impact\` before risky multi-file changes, PR reviews, routes, services, jobs, auth, billing, deployment, schema, migrations, or explicit "what is missing" assessments.
 - On paid Context plans, use \`snipara_code_symbol_card\` before editing important symbols.
 - Check every \`snipara_code_*\` response for indexed commit SHA, indexing time, included files, coverage, and freshness warnings.
-- Use \`snipara_plan\` for complex work when available; use \`snipara_decompose\` when deeper decomposition is needed and the hosted server exposes it.
+- Use \`snipara_plan\` for complex or multi-surface work when available. Keep simple Q&A on targeted \`snipara_context_query\`; for FULL-mode audits, comparisons, roadmap/implementation planning, release readiness, or package-surface reviews, use \`snipara_decompose\` to preserve axes and \`snipara_multi_query\` for independent follow-up questions when Pro+ tools are exposed.
 - Use local file reads, \`rg\`, \`git status --short\`, and tests for exact code edits and current working-tree state.
 - If a broad query is slow, retry once with a narrow keyword query before falling back to local search.
 - When \`snipara-companion\` is installed and the LLM has a visible multi-phase plan, keep the machine plan in JSON, use \`snipara-companion workflow start\`, \`phase-start\`, and \`phase-commit\` per phase, and after \`workflow resume\` rerun \`workflow phase-start\` before editing again.
@@ -2840,7 +2845,7 @@ ${guidance.map((line) => `- ${line}`).join("\n")}
 - Start substantial work with \`snipara_recall\` and \`snipara_context_query\`.
 - Use \`answer_pack\` facts, caveats, source maps, and verification checks before making claims.
 - For coding tasks, choose a workflow mode before editing: LITE for small single-phase changes, FULL managed workflow for multi-file, risky, release/deploy, architectural, compaction-prone, or future-maintainer-sensitive work.
-- Use \`snipara_plan\` for complex work when exposed; reserve \`snipara_decompose\` for FULL-mode work when the hosted server exposes it.
+- Use \`snipara_plan\` for complex or multi-surface work when exposed. Keep simple Q&A on targeted \`snipara_context_query\`; for FULL-mode audits, comparisons, roadmap/implementation planning, release readiness, or package-surface reviews, use \`snipara_decompose\` to preserve axes and \`snipara_multi_query\` for independent follow-up questions when Pro+ tools are exposed.
 - Use \`snipara_code_symbol_card\` for important symbols. For risky multi-file changes, PR reviews, routes, services, jobs, auth, billing, deployment, schema, migrations, or explicit "what is missing" assessments, use \`snipara-companion code impact\` first when companion is available; use hosted \`snipara_code_impact\` only when companion is unavailable or after push/reindex for canonical graph impact.
 - Use the installed \`snipara-companion\` binary for low-latency hooks; use \`${COMPANION_NPX_COMMAND}\` for one-off terminal commands when freshness matters.
 - If a broad query is slow, retry once with a narrow keyword query before falling back to local search.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-snipara",
-  "version": "2.0.4",
+  "version": "2.0.5",
   "description": "Onboard Snipara Hosted MCP Context + Memory with auth, companion workflows, and optional Snipara Sandbox",
   "main": "dist/index.js",
   "type": "module",