genesis-compiler 1.2.28 → 1.3.0

package/README.md

@@ -24,6 +24,7 @@ The useful mental model is:
 genesis/
   version            project-file format version used for deterministic migrations
   blueprint.md       non-technical product intent
+  collaboration.md   project-wide communication choices and authored requirements
   engineering.md     selected engineering profile and project-specific requirements
   stack.md           selected components, resources, verification, and project-owned operation contracts
   stack/             optional per-component Description, Guidance, Adoption, Post-change, and Deslop customization
@@ -200,9 +201,9 @@ complete directory into `.agents/skills/`, including its `references/`,
 must resolve within that same Skill directory after relocation; a missing
 target or path that escapes the Skill root makes the Skill invalid. The agent
 loads valid resources only when the Skill requires them. A technology does not
-need a Skill to be selectable: the curated JSKIT piece, like ordinary framework
-pieces, links its authoritative framework documentation through Stack prose and
-declares no Skill. A piece's optional `## Guidance` is concise supplemental
+need a Skill to be selectable: the curated JSKIT and Vue pieces link their
+authoritative framework documentation through Stack prose and declare no Skill.
+A piece's optional `## Guidance` is concise supplemental
 project-work guidance; it does not create or replace a generic technology
 skill.
 
@@ -237,6 +238,60 @@ Project-scoped options follow the command, for example
 a host or script needs the normalized result. Run `genesis --help` for the
 compact CLI synopsis.
 
+## Collaboration approach
+
+Genesis keeps project-wide communication guidance in ordinary source rather
+than in a host-private policy or a repeated user-message prefix:
+
+```markdown
+# Collaboration approach
+
+## Tone
+
+- `encouraging`
+
+## Response length
+
+- `concise`
+
+## Assumed experience
+
+- `comfortable`
+
+## Explanation style
+
+- `concise`
+
+## Project requirements
+
+- Nothing.
+```
+
+Inspect or change it without parsing Markdown yourself:
+
+```bash
+genesis collaboration show
+genesis collaboration set direct balanced expert conclusions "Be candid."
+```
+
+Genesis owns the supported choices and their concise expansions. Authored
+project requirements receive one fixed framing sentence and are otherwise
+preserved. They are omitted when the source says `- Nothing.`.
+
+Persistent hosts should install `projectSessionContext()` once when a provider
+conversation is created or refreshed. They may then generate task prompts with
+`sessionContextInstalled: true`, preventing the stable Collaboration and
+Engineering guidance from being repeated in each task. A host can supply one
+explicit session/turn driver; Genesis performs no driver discovery and labels
+turn output untrusted. If the project-local Codex or OpenCode adapter runs in a
+separate process, the host may set `GENESIS_HOST_CONTEXT_RESOLVER` to one
+executable and optionally supply opaque JSON in
+`GENESIS_HOST_CONTEXT_RESOLVER_DATA`. Session and turn hooks pass only the
+requested lane, native provider session id, and that configured data to the
+executable. Session output is composed into stable context; a nonempty turn
+result is capped at 512 bytes, labeled untrusted, and kept separate from the
+authored user message. This is a single process bridge, not a plugin registry.
+
 ## Engineering approach
 
 Every profile inherits one universal rule: implementation must remain easy to
@@ -518,8 +573,13 @@ The eight task types are deliberately explicit:
 - `start` opens the project conversation. For a new project it establishes what
   is being built, who or what will use or invoke it, and the first useful
   observable outcome before presenting relevant choices from the live Stack
-  catalog. A partial reply resolves only what it explicitly answers. For an
-  existing project it asks what the person wants to understand or change.
+  and engineering-profile catalogs. A partial reply resolves only what it
+  explicitly answers. An existing project receives none of those new-project
+  questions or catalogs. Its opening contains the full Blueprint, concise
+  selected Stack and Program summaries, and full selected Guidance separated by
+  component headings; detailed Program modules, sources, operations, indexes,
+  and skills are loaded later with `genesis context <relevant-path...>`. It
+  checks `genesis stack list` before proposing an additional technology.
 - `adopt` imports an existing application's factual operational and product
   contracts into Genesis metadata. It composes technology-specific Adoption
   requirements from the selected Stack and does not change application code.
@@ -645,7 +705,10 @@ General `Guidance` enriches implementation, review, Program, description, and
 cleanup tasks; `Adoption` adds import-only requirements; `Post-change` adds
 work to finish in the original implementation turn; `Deslop` adds
 technology-specific cleanup rules to Genesis's invariant behavior-preserving
-contract. None shadows an official generic technology skill or assumes that an
+contract. When several components contribute one of these prose fields,
+Genesis retains each complete contribution under its component heading in
+dependency-first selected order; it does not blend or semantically deduplicate
+their instructions. None shadows an official generic technology skill or assumes that an
 upstream skill contains every rule Genesis needs.
 
 Genesis core contains no Stack pieces and no database, framework, language, or
@@ -772,7 +835,8 @@ genesis migrate
 
 Migration is deterministic and forward-only. The format 2 migration snapshots
 the previously effective Stack operations into project-owned sections before
-removing component-runtime fallback. Migration also synchronizes managed skills
+removing component-runtime fallback; format 3 adds the portable Collaboration
+declaration. Migration also synchronizes managed skills
 and hooks, regenerates derived indexes, and then returns a fresh `check`
 result. A newer project is never downgraded. Every project-scoped CLI
 invocation warns when the recorded format does not match the running CLI, and
@@ -789,6 +853,7 @@ import {
   getContext,
   indexCodebase,
   initialize,
+  inspectCollaboration,
   inspectEngineering,
   inspectEnvironment,
   inspectStackSection,
@@ -796,6 +861,9 @@ import {
   listEngineeringProfiles,
   listStackPieces,
   migrate,
+  projectSessionContext,
+  projectTurnContext,
+  setCollaboration,
   setEngineeringProfile,
   verify,
 } from 'genesis-compiler';
@@ -810,6 +878,12 @@ codebase. `installCodex()` installs the optional global discovery plugin.
 `listEngineeringProfiles()`, `inspectEngineering()`, and
 `setEngineeringProfile()` expose the same built-in catalog and portable
 project selection used by the CLI and hosts.
+`inspectCollaboration()` and `setCollaboration()` expose the portable
+communication declaration and Genesis-owned choice expansions.
+`projectSessionContext()` composes stable project guidance with one explicitly
+supplied host-driver result. `projectTurnContext()` invokes that same optional
+driver for the separate untrusted turn lane without accepting user-message
+text.
 `getContext()` resolves source paths to the Program modules that cite them,
 the functions already declared there, selected Stack guidance, available Agent
 Skills, and verification commands. `indexCodebase()` regenerates or returns the
@@ -821,8 +895,9 @@ projection paths without returning any supplied environment value.
 interpreting or executing its contents.
 
 Normalized results identify their stable public contract in the `contract`
-field: `genesis.engineering.v1`, `genesis.environment.v2`,
-`genesis.stack-section.v1`, or
+field: `genesis.collaboration.v1`, `genesis.engineering.v1`,
+`genesis.environment.v2`, `genesis.session-context.v1`,
+`genesis.stack-section.v1`, `genesis.turn-context.v1`, or
 `genesis.verification.v1`. A consumer defines any schema embedded inside the
 opaque section body.
 

package/docs/prompt-integration.md

@@ -15,11 +15,93 @@ const work = await generatePrompt({
 await currentAgent.send(work.prompt);
 ```
 
+A persistent host installs stable context separately and keeps ordinary user
+text unchanged:
+
+```js
+import {
+  generatePrompt,
+  projectSessionContext,
+  projectTurnContext,
+} from 'genesis-compiler';
+
+const sessionContext = await projectSessionContext({
+  projectRoot,
+  hostDriver,
+  hostDriverInput: {
+    scope: 'session',
+    conversationKind: 'main',
+    session: { managedPreview: true },
+  },
+});
+await provider.installTrustedSessionContext(sessionContext.output);
+
+const task = await generatePrompt({
+  projectRoot,
+  task: 'work',
+  request: userMessage,
+  sessionContextInstalled: true,
+});
+const turnContext = await projectTurnContext({
+  hostDriver,
+  hostDriverInput: {
+    scope: 'turn',
+    actor: { preferredAddressName: 'Merc' },
+  },
+});
+await provider.sendUserTurn({
+  text: task.prompt,
+  untrustedContext: turnContext.output,
+});
+```
+
+The provider method names above are illustrative. Genesis supplies semantic
+session and untrusted-turn results; the host's provider adapter owns their
+native placement. The driver never receives or rewrites `userMessage`, and
+Genesis supports only the one explicitly supplied driver—there is no discovery
+or plugin registry.
+
+When the project-local Codex or OpenCode adapter runs in a separate process,
+the host can configure that same one-driver boundary without adding another
+prompt compositor:
+
+```text
+GENESIS_HOST_CONTEXT_RESOLVER=/path/to/host-context-resolver
+GENESIS_HOST_CONTEXT_RESOLVER_DATA={"registry":"/runtime/host-sessions.json"}
+```
+
+For `genesis hook session`, Genesis invokes that one executable with bounded
+JSON on stdin:
+
+```json
+{
+  "scope": "session",
+  "providerSessionId": "native-session-id",
+  "data": { "registry": "/runtime/host-sessions.json" }
+}
+```
+
+For `genesis hook turn`, the input has the same shape with `scope: "turn"`.
+The executable returns only the requested host contribution as text. Codex's
+hook input and OpenCode's transform callbacks supply the native session id;
+Genesis extracts that id but does not understand the host registry or the
+provider's prompt-placement rules. The Codex prompt hook and OpenCode message
+transform place a nonempty turn result separately from authored user text. If
+no resolver is configured, both turn paths are empty and the adapters render
+ordinary Genesis session context exactly as before.
+
 Tasks are `start`, `adopt`, `work`, `deslop`, `program`, `blueprint`, `describe`, and `review`.
 `start` is the host-independent first conversation: it classifies an initialized
-project from current Genesis facts, asks what a new app is about, exposes the
-live Stack catalog for an explicit user choice, or asks what the person wants
-to do with an existing project. For an existing uninitialized codebase it owns
+project from its selected Stack and Git-visible project paths without building
+the code index. A new project gets the product questions and live Stack and
+engineering-profile catalogs. An existing project gets none of that
+new-project launcher or catalog: its opening JSON contains the full Blueprint,
+selected component summaries, and only bounded Program status, subsystem names,
+and a module count. The complete effective Guidance remains present once under
+component headings. Exact Program modules, sources, project contracts, indexed
+functions, verification commands, and skills are deferred to `genesis context
+<relevant-path...>`. A new technology request goes through `genesis stack list`
+before selection. For an existing uninitialized codebase it owns
 the adoption recommendation as part of the same portable prompt. A host such as Vibe64 sends this prompt on the
 first chat turn; it does not recreate the questions or Stack catalog.
 `describe` creates or refreshes the complete Blueprint and useful Program in one
@@ -33,13 +115,17 @@ Genesis keeps each instruction at one useful level:
 - `skills/genesis-project/`, `skills/genesis-program/`, and
   `skills/genesis-deslop/` are the reusable workflow sources copied into each
   project's `.agents/skills/` directory.
-- `prompts/<task>.txt` is a task launcher. It selects the relevant
-  workflow skill and states only that turn's edit boundary.
+- `prompts/<task>.txt` is a task launcher. `start.txt` is only the common opening
+  seam; one of its new, existing, or existing-uninitialized launchers is appended
+  after classification. Each launcher states only its own project kind's work.
 - a declared Stack package's `stacks/pieces/<component>.md` supplies concise Description, supplemental
   Guidance, Adoption requirements, initial operation proposals, Deslop overlays,
   structural Indexers, and an optional authoritative Agent Skill source.
 - `genesis/blueprint.md`, `genesis/program/`, and `genesis/stack.md` are the
   project's own intent, explanation, and selected technical composition.
+- `genesis/collaboration.md` selects Genesis-owned tone, response-length,
+  assumed-experience, and explanation-style instructions plus optional authored
+  project requirements.
 - `profiles/engineering/*.md` owns the installed versioned engineering
   profiles. `genesis/engineering.md` selects one profile and records explicit
   project requirements. A universal complexity gate is composed ahead of the
@@ -50,7 +136,8 @@ Detailed technology manuals belong to the technology's authoritative
 documentation, which Stack prose may link directly. A technology may also
 offer a separately installable Skill with its own `references/` directory.
 Concise rules needed in project prompts belong in Stack `Guidance`; they are
-composed without creating a colliding generic skill.
+composed dependency-first without semantic blending and retain a heading for
+each contributing component.
 
 ## Existing projects
 
@@ -88,6 +175,21 @@ requests another model turn. Selected `Post-change` contributions are included
 in the original implementation prompt, whose project skill also keeps
 intentional Blueprint and affected Program changes aligned.
 
+An out-of-process host may configure the single resolver described above. Each
+adapter passes only its native session id to Genesis; Genesis sends that id,
+the requested lane, and explicitly configured opaque data to the resolver.
+Session output is composed with the stable guide; turn output remains a small
+untrusted item beside a selected real user turn. This is one process bridge,
+not a driver or plugin registry.
+
+Hosts that own a persistent provider conversation can call
+`projectSessionContext()` directly and pass at most one explicit host driver.
+The complete result includes Genesis Collaboration and Engineering guidance and
+has a stable identity. `projectTurnContext()` calls that driver only for a real
+turn selected by the host and labels its separate result untrusted. Hosts use
+`sessionContextInstalled: true` for task prompts only after installing the
+session result; the default command-line prompt remains self-contained.
+
 The operating guide dynamically lists only the component ids in the currently
 available Stack catalogs. The naked CLI uses an explicitly installed
 first-party `genesis-stack` package as its initial catalog without exposing the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis-compiler",
-  "version": "1.2.28",
+  "version": "1.3.0",
   "type": "module",
   "description": "An agent-independent prompt, multi-language code-index, cleanup, and verification companion with project agent guidance.",
   "repository": {
@@ -34,6 +34,9 @@
     "prompts/program.txt",
     "prompts/review.txt",
     "prompts/start.txt",
+    "prompts/start-existing.txt",
+    "prompts/start-existing-uninitialized.txt",
+    "prompts/start-new.txt",
     "prompts/work.txt",
     "plugins/genesis",
     "plugins/opencode",

package/plugins/genesis/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "genesis",
-  "version": "1.2.28",
+  "version": "1.3.0",
   "description": "Makes Codex aware of optional Genesis adoption for existing projects.",
   "author": {
     "name": "Mobily Enterprises"

package/plugins/opencode/project-guidance.js

@@ -5,12 +5,18 @@ import { promisify } from "node:util";
 
 const execute = promisify(execFile);
 
-async function renderProjectContext(projectRoot) {
+const HOST_CONTEXT_INPUT_ENV = "GENESIS_HOST_CONTEXT_INPUT";
+
+async function renderContext(projectRoot, sessionId, scope) {
   const { stdout } = await execute(
     "genesis",
-    ["hook", "session", "--project-root", projectRoot],
+    ["hook", scope, "--project-root", projectRoot],
     {
       cwd: projectRoot,
+      env: {
+        ...process.env,
+        [HOST_CONTEXT_INPUT_ENV]: JSON.stringify({ sessionId })
+      },
       maxBuffer: 256 * 1024,
       timeout: 5_000
     }
@@ -25,13 +31,13 @@ function eventSessionId(event = {}) {
 }
 
 export const GenesisProjectGuidance = async ({ directory, worktree } = {}) => {
-  const projectRoot = path.resolve(worktree || directory || process.cwd());
+  const projectRoot = path.resolve(directory || worktree || process.cwd());
   const contexts = new Map();
 
   function contextForSession(sessionId) {
     let context = contexts.get(sessionId);
     if (!context) {
-      context = renderProjectContext(projectRoot);
+      context = renderContext(projectRoot, sessionId, "session");
       contexts.set(sessionId, context);
       context.catch(() => {
         if (contexts.get(sessionId) === context) contexts.delete(sessionId);
@@ -50,7 +56,37 @@ export const GenesisProjectGuidance = async ({ directory, worktree } = {}) => {
       const sessionId = String(input.sessionID || input.sessionId || "").trim();
       if (!sessionId) return;
       const context = await contextForSession(sessionId);
-      if (!output.system.includes(context)) output.system.push(context);
+      if (context && !output.system.includes(context)) output.system.push(context);
+    },
+    "experimental.chat.messages.transform": async (...hookArguments) => {
+      const output = hookArguments[1] || {};
+      const messages = Array.isArray(output.messages) ? output.messages : [];
+      const messageIndex = messages.findLastIndex((message) => message?.info?.role === "user");
+      if (messageIndex < 0) return;
+      const message = messages[messageIndex];
+      const sessionId = String(message.info?.sessionID || "").trim();
+      const messageId = String(message.info?.id || "").trim();
+      if (!sessionId || !messageId || !Array.isArray(message.parts)) return;
+      const context = await renderContext(projectRoot, sessionId, "turn");
+      if (!context || message.parts.some((part) => part?.synthetic === true && part?.text === context)) {
+        return;
+      }
+      output.messages = messages.map((candidate, index) => index === messageIndex
+        ? {
+            ...candidate,
+            parts: [
+              ...candidate.parts,
+              {
+                id: `${messageId}_genesis_turn_context`,
+                messageID: messageId,
+                sessionID: sessionId,
+                synthetic: true,
+                text: context,
+                type: "text"
+              }
+            ]
+          }
+        : candidate);
     }
   };
 };

package/prompts/start-existing-uninitialized.txt

@@ -0,0 +1,8 @@
+This is an existing project without Genesis project context. Do not ask
+new-project product-discovery questions. Ask what the person wants to understand
+or change and strongly recommend preparing the project for guided editing before
+substantial work. Explain in product language that preparation preserves the
+implementation while importing its current product, setup, run, data, preview,
+and verification facts. Do not require the person to know Genesis terminology or
+type a command. If they approve, run the Genesis `adopt` operation and follow its
+prompt. If they decline, continue normally and do not repeat the recommendation.

package/prompts/start-existing.txt

@@ -0,0 +1,23 @@
+The project already exists. Do not ask new-project product-discovery questions
+and do not offer an unselected technology catalog. Use the Blueprint as product
+intent, the selected Stack summary and full guidance as technical direction, and
+the compact Program status only as orientation. If USER REQUEST is actionable,
+proceed with it. Otherwise ask what the person wants to understand or change.
+
+After locating the relevant source, run the Genesis `context <relevant-path...>`
+operation before implementation to load the exact Program modules, project
+contracts, indexed functions, verification commands, and applicable skills.
+
+If the user requests an unselected technology, run the Genesis `stack list`
+operation first. For one exact match, ask whether to add it and prepare the
+project with its official guidance; only after confirmation run `stack add
+<piece...>` and follow its preparation prompt. If nothing matches, use the
+technology's authoritative documentation without inventing a component.
+
+When no Stack is selected, inspect the project's actual scripts, build and setup
+files, server entrypoint, and readiness behavior before recording a technology.
+Component proposals are not evidence, and selecting a component does not port an
+older implementation. Preserve evidenced project-owned contracts in their
+consumer's current schema. If the existing implementation is not usefully
+explained, recommend the Genesis description path instead of pretending its
+intent or operations are known.

package/prompts/start-new.txt

@@ -0,0 +1,27 @@
+The project is new. Before technology research or source creation, establish
+what is being built, who or what will use or invoke it, and the first observable
+useful outcome. Ask at most three concise questions at a time, and do not repeat
+facts already supplied by the user. A Stack choice is not product intent.
+
+Use `availableStackPieces` to offer only relevant technology choices in product
+language. Never silently select one. If the user names an unselected technology,
+run the Genesis `stack list` operation first. For one exact match, ask whether to
+add it and prepare the project with its official guidance. On confirmation, run
+the Genesis `stack add <piece...>` operation, follow its preparation prompt in
+this task, then run `context .` or `context <relevant-path>` and load any
+applicable installed skill. Never infer an install command from a component id.
+If the user declines, do not ask again; if nothing matches, use the technology's
+authoritative documentation without inventing a component.
+
+Establish the non-technical Blueprint before implementation. If product intent
+is clear while Stack is empty, present the relevant Stack choices in this same
+turn. The default `focused.v1` engineering profile suits ordinary work; use
+`availableEngineeringProfiles` only when the user requests another approach or
+the product has material long-lived compatibility, operational, security,
+reliability, or compliance constraints. Apply an explicit choice with the
+Genesis `engineering set <profile>` operation.
+
+This opening owns product direction and Stack selection, not final verification.
+Do not run the Genesis `verify` operation before implementation exists. Use
+`check` only when structural validation is useful. Once direction and Stack are
+clear, follow one smallest implementation path through the selected guidance.

package/prompts/start.txt

@@ -1,87 +1,5 @@
 Read and follow `.agents/skills/genesis-project/SKILL.md` completely.
 
-This is the project-opening conversation. For a new project, do not begin
-technology research or create source until the user has made clear what is
-being built, who or what will use or invoke it, and the first observable useful
-outcome. Ask only unresolved high-impact questions. A reply confirms only what
-it explicitly answers; Stack confirmation is not product intent.
-
-When the user explicitly names a technology, framework, language, or database
-that is not selected, make the existing Genesis `stack list` operation the
-first technology action. If one catalog component exactly matches that choice,
-ask: "<Technology> is available in Genesis. Would you like me to add it to this
-project and prepare the app with its official guidance?" Do not run `stack add
-<piece...>` without that confirmation. If confirmed, add it, let Genesis apply
-its declared dependency closure and synchronize any skill the component
-declares. Follow the preparation prompt returned by `stack add` in this same
-task: make each materialized project contract true or replace a complete
-section with evidenced reality. Then run `context .` (or the relevant source
-path once source exists), load the applicable installed skill if present, and
-follow the technology-owned guidance to prepare actual project dependencies.
-Never infer an install command from a component id. If declined, continue
-without adding it or asking again.
-If no component matches, do not invent one; continue normally using
-authoritative technology documentation.
-
-When `projectKind` is `new`, establish what is being built, who or what will use
-or invoke it, and its first observable useful outcome. Ask up to three concise,
-high-impact questions at a time, and ask access, data, platform, or interface
-questions only when they are material to that product. Use
-`availableStackPieces` to present only the relevant choices, explain them in
-product language, and let the user decide. Never silently select a technology.
-After the user confirms the proposed component selection, use the Genesis
-`stack add <piece...>` operation; do not edit `genesis/stack.md` by hand.
-Establish the non-technical Blueprint from the user's answers before
-implementation.
-If the product direction becomes clear while Stack is still empty, do not end
-the turn after only writing or summarizing the Blueprint: present the relevant
-Stack choices in that same turn and ask the user to select one explicitly.
-The default `focused.v1` engineering profile is already suitable for ordinary
-work, so do not force a separate profile question. When the user asks for a
-different engineering approach, or the product clearly has long-lived
-compatibility, operational, security, reliability, or compliance constraints,
-use `availableEngineeringProfiles` to explain only the relevant choices in
-product language. After an explicit choice, run the Genesis `engineering set
-<profile>` operation; do not invent or duplicate a built-in profile. Record
-additional explicit obligations in `genesis/engineering.md` under Project
-requirements.
-This opening turn owns product direction and Stack selection, not final
-verification. Do not run the Genesis `verify` operation before implementation
-exists. If structural validation is useful, run the Genesis `check` operation;
-consumer-owned operations remain governed by their own tools and must not be
-inferred here.
-
-When `projectKind` is `existing`, ask what the user wants to understand or
-change. Use the current Blueprint, Stack, Program, and code index when present.
-If the existing implementation is not yet explained, recommend the Genesis
-description/adoption path instead of pretending its intent is known.
-When an existing implementation has no selected Stack yet, inspect its actual
-package scripts, build files, setup commands, server entrypoint, and readiness
-route before recording the user's technology choice. Materialized component
-proposals describe that component's current operational foundation; selecting
-the component does not port an older implementation to it. If the existing
-facts differ, replace the complete project-owned section using the consumer's
-current schema and the code that exists. Never report a proposed operation as
-usable merely because the component was selected, and never add compatibility
-implementation without the user asking for a port.
-
-When `projectKind` is `existing-uninitialized`, ask what the user wants to
-understand or change and strongly recommend preparing the existing project for
-guided editing before substantial work. Explain in product language that this
-preserves the implementation while importing its current setup, run, database,
-preview, verification, and product context. Do not require the user to know
-Genesis terminology or type a command. If they approve, run the Genesis `adopt`
-operation yourself and follow its adoption prompt. If they decline, continue
-normally and do not repeat the recommendation.
-
-If the request already contains an unambiguous product description and an
-explicit Stack choice, establish the Blueprint and ask for the component
-confirmation described above before applying that choice. Otherwise this is a
-conversational turn: ask, listen, and preserve the source.
-
-Once product direction and any relevant Stack selection are clear, choose one
-smallest implementation path through the applicable technology guidance, or
-authoritative technology documentation when the catalog has no match, and read
-only what that path requires. Do not survey alternative foundations, clone
-whole technology repositories, inspect unrelated package internals, or
-delegate research unless one concrete failure requires one exact investigation.
+This is the project-opening conversation. Follow only the project-kind
+instructions below. Treat USER REQUEST as the person's actual request, preserve
+what it already establishes, and ask only unresolved high-impact questions.