genesis-compiler 1.2.12 → 1.2.14

package/README.md

@@ -13,7 +13,7 @@ interaction.
 ```text
 genesis/
   blueprint.md       non-technical product intent
-  stack.md           selected technology guidance, checks, setup, launch, and deployment data
+  stack.md           selected technology guidance, verification, declarations, and opaque extensions
   stack/             optional per-component Description, Guidance, Adoption, and Deslop customization
   program/           concise explanations grouped into conceptual subsystems
 .agents/skills/
@@ -73,12 +73,11 @@ genesis adopt "Optional product guidance"
 
 It preserves the implementation, initializes the Genesis files and local
 hooks, and prints the `adopt` prompt. That prompt imports the existing
-application's factual Stack contract—including setup, environment/resources,
-database preparation and seed, Launch/readiness, Preview identity,
-verification, and deployment—then creates the first useful Blueprint and
-Program. Give it to the agent already working in the repository. Adoption edits
-Genesis metadata only; implementation modernization remains a separate,
-explicitly approved port. “Adopt” never moves the project.
+application's factual Stack declarations—including environment/resources,
+verification, and consumer-owned opaque sections—then creates the first useful
+Blueprint and Program. Give it to the agent already working in the repository.
+Adoption edits Genesis metadata only; implementation modernization remains a
+separate, explicitly approved port. “Adopt” never moves the project.
 
 For a new or empty project, initialize first and write the product intent:
 
@@ -137,26 +136,6 @@ Genesis never overwrites an unmanaged skill and preserves locally modified
 managed skills. Run `genesis init` after manually editing `genesis/stack.md`,
 or use `genesis stack add`, to synchronize selected skills.
 
-Run `genesis prepare` to execute the selected Stack's exact workspace recipe
-directly with the caller's environment and installed toolchain. It executes
-argument arrays without a shell, honors declared project-relative working
-directories and conditional paths, stops on the first failure, and never
-returns environment values. Hosts that need their own runtime, permission, or
-process policy can instead call the public `inspectWorkspaceSetup()` API and
-execute the same normalized recipe themselves. A concrete Stack piece may declare one exact,
-ordered `## Workspace setup` recipe with labels, argument arrays expressed as
-backticked tokens, abstract runtimes, and optional project-relative working
-directories and readiness paths. A recipe whose declared project marker does
-not exist remains unconfigured until a later inspection. The catalog's
-`jskit` piece waits for `package.json` and then declares `npm install`; generic
-`nodejs` and `php` deliberately declare no installer. One project section in
-`genesis/stack.md` replaces all component defaults, including with
-`- Nothing.`. Without that override, exactly one component recipe is used;
-multiple component recipes are reported as ambiguous and never merged.
-The standalone command does not provision declared resources: callers provide
-their own database, credentials, compilers, and other infrastructure. Stack
-resources such as database variables do not gate dependency installation.
-
 Hosts that manage project environments can call `inspectEnvironment()`.
 Concrete Stack integrations may declare public, non-secret Environment
 defaults such as the database driver selected by that integration. Explicit
@@ -176,52 +155,30 @@ value-free missing-input diagnostics, and paths. It never returns supplied
 environment values, writes files, stores secrets, or decides which resolved
 host values should be materialized.
 
-Hosts that provide previews can call the public `inspectLaunch()` API. An
-optional readable `## Launch` section in `genesis/stack.md` declares labeled
-targets, exact backticked argument tokens, relative working directories,
-abstract runtime requirements, `{host}`/`{port}` substitutions, and an optional
-application-owned Preview identity block. Concrete components may provide a
-default: the catalog's `jskit` piece declares its app-owned `npm run develop`
-command; generic
-`nodejs` and `php` do not guess. Genesis starts nothing itself. It returns preview identity
-command metadata and environment variable names, never their values. The host
-continues to own pinned runtimes, ports, processes, readiness probing and
-timeouts, identity-command execution and secrets, browser binaries, Git, and
-credentials. Genesis owns only the exact HTTP readiness predicate declared by
-the selected Stack. See
-[`docs/stack-components.md`](docs/stack-components.md) for the v1 contract.
-
-Hosts that publish applications can call the separate public
-`inspectDeployment()` API. An optional readable `## Deployment` section
-declares an ordered production recipe: project-relative workdir, abstract
-runtimes, exact Prepare/Build/Migrate/Serve argv, and one HTTP readiness
-predicate. A concrete component may provide the recipe; the catalog's `jskit`
-piece declares production dependency installation, build, database preparation,
-`npm start`, and `/api/health`. Generic language pieces do not guess. A project
-section replaces component defaults wholesale, and `- Nothing.` explicitly
-disables publishing.
-
-Genesis only validates and reports this recipe and the Stack's abstract resource
-requirements. It does not provision a database, resolve credentials, copy a
-release, run commands, start a service, reserve a port, route traffic, issue TLS,
-or roll back. A deployment host owns all of those operational responsibilities,
-including the mapping from `mysql` or `postgresql` resources to its managed
-services.
+Consumers may define additional `##` sections in a project or component Stack.
+Genesis composes each section by name, includes its exact text in Stack identity
+and prompt context, and exposes it through `inspectStackSection()`. The body is
+opaque: Genesis does not parse its commands, infer its purpose, or execute it.
+A project section replaces a component default of the same name; competing
+component declarations are reported mechanically instead of merged.
+
+This is the boundary for every consumer-specific operation. The consumer that
+names a section owns its schema, validation, runtime mapping, execution, and
+proof of success. Genesis has no model of starting, preparing, deploying,
+packaging, migrating, serving, probing, or supervising a project. A web host,
+native toolchain, firmware publisher, desktop signer, or any future consumer
+can define different sections without a Genesis compiler change.
 
 Standalone and non-Node hosts can inspect these same normalized contracts
 without importing the JavaScript API or parsing Markdown:
 
 ```bash
-genesis inspect workspace --json
 genesis inspect environment --json
-genesis inspect launch --json
-genesis inspect deployment --json
+genesis inspect section 'Consumer operation' --json
 ```
 
 Without `--json`, the commands print concise human-readable summaries. They
-never start the application, probe a server, materialize environment files, or
-deploy. `genesis prepare` is the separate explicit command that executes only
-the finite Workspace setup recipe.
+never interpret or execute a consumer-owned section.
 
 At session start, Codex receives only a short explanation of how Genesis is
 organized. After it locates the source involved in a request, it can load the
@@ -416,10 +373,8 @@ Run the Stack's declared checks explicitly:
 genesis verify
 ```
 
-Genesis first waits for any technology-declared Workspace setup marker. A
-missing marker is `unconfigured`, not a failed command. Once the workspace
-exists, Genesis applies public Stack defaults beneath explicit environment
-values, evaluates generic resource declarations, and runs each declared
+Genesis applies public Stack defaults beneath explicit environment values,
+evaluates generic resource declarations, and runs each declared Verification
 command without a shell. A complete successful run writes only
 `.genesis/verification.json`, recording:
 
@@ -436,7 +391,7 @@ whole-product correctness.
 A project can replace component defaults in `genesis/stack.md`:
 
 ```markdown
-## Commands
+## Verification
 
 - Verify `tests`: `npm` `test`
 - Verify `build`: `npm` `run` `build`
@@ -453,8 +408,8 @@ genesis check
 - Blueprint and Stack validity;
 - selected Agent Skill presence and structural validity;
 - Program presence and structural validity;
-- Workspace setup, environment, Launch, and Deployment as `ready`, `blocked`,
-  or honestly `unconfigured`;
+- environment declarations and consumer-owned Stack extensions as `ready`,
+  `blocked`, or honestly `unconfigured`;
 - missing Stack-declared environment inputs (without claiming the service is
   reachable);
 - verification evidence as `current`, `stale`, `missing`, `invalid`, or
@@ -479,10 +434,8 @@ import {
   getContext,
   indexCodebase,
   initialize,
-  inspectDeployment,
   inspectEnvironment,
-  inspectLaunch,
-  inspectWorkspaceSetup,
+  inspectStackSection,
   installCodex,
   listStackPieces,
   verify,
@@ -497,25 +450,16 @@ codebase. `installCodex()` installs the optional global discovery plugin.
 the functions already declared there, selected Stack guidance, available Agent
 Skills, and verification commands. `indexCodebase()` regenerates or returns the
 detailed Machine City and simple Program City projections.
-`inspectWorkspaceSetup()` returns one normalized, shell-free workspace
-preparation recipe—or an explicit unconfigured or ambiguous result—for a host
-to execute with its own pinned runtimes, caches, process isolation, and
-credentials. A configured recipe may remain unconfigured while it waits for a
-technology-declared project marker.
 `inspectEnvironment()` returns normalized Stack resource declarations,
 public non-secret defaults, value-free missing-input diagnostics, and dotenv
 projection paths without returning any supplied environment value.
-`inspectLaunch()` returns a validated, normalized Stack launch declaration for
-a host to execute with its own runtime, port, process, readiness probe, preview
-identity, secret, and browser policy.
-`inspectDeployment()` returns the separate normalized production recipe without
-executing or provisioning it.
-
-Normalized operational results identify their stable public contract in the
-`contract` field: `genesis.workspace-setup.v1`, `genesis.environment.v1`,
-`genesis.launch.v1`, `genesis.deployment.v2`, or
-`genesis.verification.v1`. Hosts validate that identity instead of
-feature-detecting individual fields.
+`inspectStackSection()` returns one exact consumer-owned section without
+interpreting or executing its contents.
+
+Normalized results identify their stable public contract in the `contract`
+field: `genesis.environment.v1`, `genesis.stack-section.v1`, or
+`genesis.verification.v1`. A consumer defines any schema embedded inside the
+opaque section body.
 
 A host such as Vibe64 can send the generated prompt to its existing agent:
 

package/docs/prompt-integration.md

@@ -37,7 +37,7 @@ Genesis keeps each instruction at one useful level:
   workflow skill and states only that turn's edit boundary.
 - a declared Stack package's `stacks/pieces/<component>.md` supplies concise Description, supplemental
   Guidance, Adoption requirements, Resources, Deslop overlays, structural Indexers, verification
-  Commands, and an optional authoritative Agent Skill source.
+  commands, opaque consumer sections, 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.
 - The generated JSON block contains current structural facts and warnings.
@@ -59,10 +59,10 @@ then creates one Blueprint and subsystem-oriented Program.
 
 Adoption does not upgrade an application's technology foundation. Component
 defaults apply only when direct source evidence matches. Older or otherwise
-different applications receive complete project-owned declarations for setup,
-environment/resources, Launch and Preview identity, verification, and
-deployment as applicable, so a host never executes a newly selected
-component's current command against source that does not provide it.
+different applications receive complete project-owned environment/resource,
+Verification, and consumer-owned opaque declarations as applicable. Genesis
+does not interpret those opaque bodies; the consumer's schema and technology
+skill determine what must be preserved.
 
 Codex users can run `genesis codex install` once to install the packaged
 Genesis discovery plugin. Its `SessionStart` hook executes before the first