silvermoon 0.3.0-rc.2 → 0.4.0

package/skills/silvermoon/SKILL.md

@@ -59,27 +59,59 @@ upstream, network, or primary ancestry. It never fetches. Use its repeatable
 for those filters; the default is all active ideas.
 
 `whats-next` may fetch and inspect but never changes files, branches, index, or
-refs. `create-idea` requires the configured primary branch and upstream plus a
-clean worktree; it does not fetch or compare ancestry.
+refs. `create-idea` requires a local branch whose upstream identifies the
+configured primary repository and branch, plus a clean worktree. The local
+branch name is unrestricted; it does not fetch or compare ancestry.
 
-`check` validates only a project snapshot; it does not navigate ideas or check
-repository synchronization. Default `check` validates committed `HEAD`;
+`check` validates a project snapshot and, for v2 projects, its event history
+against primary. It does not navigate ideas or perform synchronization.
+Default `check` validates committed `HEAD`;
 `--worktree` validates the full candidate and `--staged` the index. Its JSON
 uses the same four projections; only `check --remote` normally records an
 action. Exit `0` means valid, `1` invalid or unavailable, and `2` invalid
 usage. Never commit unless the relevant check exits `0`.
 
-A repository without a root `package.json` needs no package manager,
-Silvermoon dependency, or `node_modules`. When the root manifest exists, it
-must be valid JSON and declare `devDependencies.silvermoon` as exactly
-`^<running-version>`; follow the reported package-manager-specific
-remediation. Register npm projects' skill from
-`./node_modules/silvermoon/skills` after installing root dependencies. Other
-repositories use the skill bundled with the running installation. Snapshot
-checks do not require installed dependencies, and Silvermoon reports setup
-problems without modifying project files or registering skills. Register the
-canonical skill at `.agents/skills/silvermoon` with the supported
-`npx skills add` universal target.
+Silvermoon runtime and skill installation are device or host concerns, not
+project metadata. Never add Silvermoon to a target repository's dependency
+manifest, resolve a CLI from its `node_modules`, or create a repository-local
+Silvermoon skill. The host exposes the running installation's canonical skill
+through a personal discovery path such as `~/.agents/skills/silvermoon` or
+`~/.copilot/skills/silvermoon`; register it globally by link rather than copy.
+Project snapshot checks inspect Git, Silvermoon configuration, metadata schema,
+and layout only. They do not read `package.json`, `node_modules`, or repository
+skill paths.
+
+Treat `response.device` as a non-blocking execution-environment advisory, not a
+project finding. Surface an available global-runtime update and repair missing,
+broken, or stale personal skill links at the device or Agent host. Successful
+npm `latest` observations may be reused for less than 24 hours; registry
+failure never makes a valid project snapshot fail. Snapshot-only `check`
+commands intentionally omit device readiness.
+
+Read `observation.schemas` as two independent axes. `validity` says whether
+the running runtime can validate the file; `readiness` says whether the file
+is at that runtime's current write target. A valid historical file may pass
+snapshot `check` and remain readable through `list-ideas`, while
+`whats-next` and write preparation require its declared migration first.
+Never edit or guess a future schema. Project preparation forces one
+latest-runtime refresh and reports whether an update exists, the confirmed
+latest still lacks support, or registry freshness is unavailable.
+
+When preparation reports `migration-required`, use the exact migration path
+declared in `observation.schemas`; do not edit only a version field. With an
+installed global runtime, plan `project-v1-to-v2` through
+`silvermoon-migrate-v1-to-v2 --root <project>`, then apply only the returned
+digest after explicit upgrade authorization. In this source checkout, use
+`node bin/migrate-v1-to-v2.ts` instead. Migration never commits, pushes, or
+records a lifecycle decision.
+
+Silvermoon's own source repository is exempt from the dependency requirement.
+There, use `node bin/silvermoon.js` from the current checkout for every
+`silvermoon` command in this skill, preserving all arguments and options.
+Never add Silvermoon as its own dependency or use a globally installed,
+published, or different checkout's runtime while working in this repository.
+Maintain its canonical skill in `skills/silvermoon` and refresh the registered
+copy with `pnpm sync:skills`, not from `node_modules`.
 
 ## Follow One Report
 
@@ -127,17 +159,27 @@ Missing guidance is normal. A guidance problem blocks only the reported
 current action until repaired. `check` validates all three fixed guidance files
 in its selected snapshot but never returns their content.
 
+Every selected v2 report projects `selectedIdea.control` and all three
+`selectedIdea.submissions`. Treat `downstream` as Agent-side control,
+`upstream` as upstream/user-side control, and `none` as terminal. A stale
+current-phase submission returns effective control downstream. `response.review`
+appears only when the exact current phase revision is submitted and control is
+upstream; before that, follow `response.nextSteps` instead of asking for the
+corresponding acceptance.
+
 ## Execute The Workflow
 
 ### Create A New Idea
 
 `create-idea` creates only the scaffold: `Idea.md`, `Implementation.md`,
-`Deployment.md`, `ledger.md`, and `status.yaml`. It never stages, commits,
-pushes, or records a decision. Preserve explicit creation intent through
-hygiene retries: retry `create-idea`, not bare `whats-next`.
-
-When creating a new idea, proactively assign a concise, unique alias in its
-`status.yaml`: use an alias supplied by the user, or derive one from the idea's
+`Deployment.md`, `ledger.md`, and either v1 `status.yaml` or v2
+`events.jsonl`. It never stages, commits, pushes, or records a decision.
+Preserve explicit creation intent through hygiene retries: retry
+`create-idea`, not bare `whats-next`.
+
+When creating a new idea, proactively assign a concise, unique alias: edit
+v1 `status.yaml`, or use v2 `event append` with `setAlias`.
+Use an alias supplied by the user, or derive one from the idea's
 goal. Do not leave the alias absent or ask for a name solely to choose one.
 
 Pass `create-idea --language <tag>` only when the user explicitly requests a
@@ -147,27 +189,33 @@ language without a built-in template, replace every natural-language
 placeholder with the exact reported content language before treating the
 contract as ready.
 
-During preparation, complete `Idea.md`. Keep the Implementation, Deployment,
-and matching ledger placeholders synchronized until their lifecycle actions.
+During preparation, turn the scaffold into the preparation candidate defined
+under **Maintain The Artifacts**. Treat scaffold sections as prompts, not
+invitations to fill space, then validate and synchronize the candidate before
+moving to unrelated work.
 
 ### Continue A Selected Idea
 
-Use the reported `ledgerPath` after lifecycle hygiene and continue only the
-selected world's unfinished work:
+Use the reported `ledgerPath` after lifecycle hygiene and continue the selected
+phase while preserving the nested worlds:
 
-- **Preparing:** Edit `Idea.md` and supporting Ideal World (理想世界) files.
-  Supporting files serve the contract, not replace it. The human gate is
-  approval of the exact reported `idealRevision`.
+- **Preparing:** Complete `Idea.md` and supporting Ideal World (理想世界) files.
+  Keep the idea as a brief direction card and prepare the downstream seeds
+  defined below. The seeds are feasibility context, not part of the acceptance
+  scope. The human gate accepts only the exact reported `idealRevision`.
 - **Implementing:** Edit `Implementation.md`, supporting Inner World (主体世界)
-  files, and repository deliverables. Change the ideal only if it truly changed
-  and the idea must return to preparing. The human gate is acceptance of the
-  exact reported `implementationRevision`.
+  files, and repository deliverables by refining the preparation seed. Change
+  the ideal only if it truly changed and the idea must return to preparing.
+  Expand the plan only as concrete work requires it. Preserve the Deployment
+  seed unless implementation creates a material external requirement. The
+  human gate is acceptance of the exact reported
+  `implementationRevision`.
 - **Deploying:** Use `Deployment.md` and supporting Outer World (现实世界)
-  files to drive and verify external outcomes; do not change repository
-  deliverables. Synchronize a new or materially changed deployment contract to
-  primary first, reobserve its stable `deploymentRevision`, then run checks
-  against it and record evidence in the ledger. The human gate is acceptance
-  of that exact revision.
+  files by refining the preparation seed to drive and verify external outcomes;
+  do not recap implementation or change repository deliverables. Synchronize a
+  new or materially changed deployment contract to primary first, reobserve its stable
+  `deploymentRevision`, then run checks against it and record evidence in the
+  ledger. The human gate is acceptance of that exact revision.
 - **Abandoned:** Keep canonical `abandoned: true`, remove it only after an
   explicit reversal, or choose another idea.
 - **Completed:** Revise its definition or create a different idea.
@@ -178,7 +226,7 @@ Each idea has three canonical entries:
 
 ```text
 .silvermoon/ideas/<ULID>/
-├── status.yaml
+├── status.yaml (v1) or events.jsonl (v2)
 ├── ledger.md
 └── outer/
     ├── Deployment.md
@@ -194,31 +242,55 @@ is the Outer World (现实世界) real-world deployment contract. Each world may
 contain supporting files, but those artifacts serve the same-world entry and
 never define a second contract.
 
+Use progressive elaboration in every world. Record only the durable information
+needed for the current gate, link existing context instead of copying it, and
+add supporting files only for a concrete decision, risk, disagreement, or
+proof that would make the canonical contract unclear. Preparation is the one
+exception to strict phase-local authoring: it seeds both downstream contracts
+at a high level so feasibility is visible before Idea acceptance. Do not
+pre-author speculative architecture, exhaustive task trees, execution
+evidence, or detailed future-phase work.
+
+`Idea.md` is a short direction card: a concise title; a problem and outcome of
+one or two sentences each; one to three material boundaries and acceptance
+criteria; and at most one current preparation step, removed before acceptance.
+Keep implementation design out of the ideal contract.
+
 In `Implementation.md` and `Deployment.md`, put plans under `## Steps` and
 outcomes under `## Acceptance criteria`. Use stable level-three IDs: `I-Sxx`,
 `I-ACxx`, `D-Sxx`, and `D-ACxx`. Each criterion states an observable outcome
-and how to prove it. Do not put checkboxes in world contracts. World content
-changes its world revision and containing revisions; `status.yaml` and
-`ledger.md` are outside those trees.
-
-The required idea-root `ledger.md` is operational memory, not a fourth world,
-contract, or human decision. Mirror the stable IDs and short titles for
+and how to prove it. Before Idea acceptance, replace every scaffold placeholder
+with a lightweight first version of no more than three high-level steps and
+three criteria per contract. Later phases refine these seeds and add another
+item only for independently necessary work or proof. Do not repeat the prior
+world or let the Implementation contract absorb Deployment detail. Do not put
+checkboxes in world contracts. World content changes its world revision and
+containing revisions; `status.yaml`/`events.jsonl` and `ledger.md` are outside
+those trees.
+
+The required idea-root `ledger.md` is an execution checklist only, not
+operational prose, a decision log, a discussion record, or a fourth world. It
+contains only the mirrored checkbox lists for Implementation and Deployment
+steps and criteria. Do not record work notes, explanations, discussion history,
+or extra sections in `ledger.md`. Mirror the stable IDs and short titles for
 Implementation and Deployment steps and criteria. Update ledger entries with
 their contract changes; add new items unchecked and reset completed items when
 requirements or proof change materially.
 
-If relevant entries remain unchecked, continue the reported work. If they are
-all checked, evidence remains valid, and the candidate is synchronized to
-primary, stop and request the appropriate explicit human decision. A checked
-box records Agent work only; it never approves, accepts, changes status, or
-authorizes synchronization.
+Only the current phase's entries govern gate readiness. During preparation,
+all seeded `I-*` and `D-*` entries remain unchecked and do not block Idea
+acceptance. During implementation, continue while a relevant `I-*` entry is
+unchecked; during deployment, do the same for `D-*`. When the current phase's
+entries are complete, evidence remains valid, and the candidate is
+synchronized to primary, request the appropriate explicit human decision. A
+checked box records Agent work only; it never approves, accepts, changes
+status, or authorizes synchronization.
 
 ## Validate And Synchronize To Primary
 
-Every successfully created idea must be completed, validated, committed, and
-synchronized to the configured primary branch before requesting review or
-approval, or moving on to unrelated work. Apply the same sequence to every
-lifecycle candidate:
+Before requesting review or moving to unrelated work, make every created or
+updated lifecycle candidate ready for its current gate, then validate, commit,
+and synchronize it to the configured primary branch:
 
 1. Inspect the complete candidate and preserve unrelated work.
 2. Run `silvermoon check --worktree`.
@@ -229,6 +301,10 @@ lifecycle candidate:
 7. Synchronize through ordinary non-force Git.
 8. Confirm the commit is reachable from refreshed primary.
 9. Reobserve the selected idea and exact world revision.
+10. In v2, when current-phase work and evidence are complete, append the
+    corresponding `submitIdeal`, `submitInner`, or `submitOuter` for that exact
+    synchronized revision, integrate the event normally, and reobserve before
+    entering the human gate.
 
 Do not ask the user whether to commit, push, or synchronize a candidate when
 those actions are required to reach its next lifecycle gate. They are Agent
@@ -249,73 +325,89 @@ recovery condition, and stop before the human gate.
 
 ## Request Focused Review And Record Decisions
 
-Enter a human gate only after the candidate is synchronized to primary and
-`whats-next` has reported its exact world revision and effective content
-language.
-
-Keep the human review message short. Treat it as an index to durable
-repository artifacts, not as the evidence container. Before requesting a
-decision, record review-relevant details in the current world or `ledger.md`,
-then synchronize those files to primary.
-
-The review index must:
-
-- identify the idea by alias and ULID, the requested decision, the exact world
-  revision, and the primary commit;
-- state the review focus in one short sentence;
-- list every directly relevant canonical contract, same-world supporting file,
-  evidence file, ledger, key deliverable, or candidate diff;
-- provide a host-clickable local link and an immutable remote link for each
-  item when available;
-- end with one explicit decision question for the exact revision.
-
-Render the review index in ordinary assistant Markdown. If an interactive
-decision tool is available, invoke it only after that message and keep its
-question and choices limited to the exact decision. Do not put local file links
-in tool-owned question or choice surfaces; those surfaces may report valid
-workspace paths as unresolved resources.
-
-Use the latest report's effective content language for the review focus, link
-descriptions, and decision question. A temporary output language does not
-change this rule. Preserve aliases, ULIDs, revisions, paths, stable IDs, and
-other machine identifiers unchanged.
-
-For ideal approval, link `Idea.md`, every relevant Ideal World supporting file,
-the downstream contract placeholders, and `ledger.md`. For implementation
-acceptance, link `Implementation.md`, Inner World supporting files, `ledger.md`,
-key source and test files, durable evidence, and the candidate diff. For
-deployment acceptance, link `Deployment.md`, Outer World evidence, `ledger.md`,
-and relevant external results.
-
-Local links are navigation conveniences and must not be described as the exact
-candidate if the local checkout has moved. Remote links should be a
-commit-pinned web URL to the primary candidate, not a moving branch URL. If no
-reliable remote permalink can be formed, provide the primary commit and
+Enter a human gate only after the current phase's contract, ledger, and
+evidence are ready, the candidate is synchronized to primary, and a fresh
+`whats-next` returns `response.review` for the current revision with upstream
+control. For v2, this requires the Agent's matching `submit*`; an absent or
+stale submission means continue downstream work and do not ask for acceptance.
+Follow the latest `response.nextSteps` for the gate procedure and use
+`response.review` as the authority for full object IDs, minimum documents,
+primary commit, and human-facing presentation. Show only 12-character revision
+and commit references to the user; retain the full values for decision
+recording.
+
+Before the gate, put review-relevant detail in durable current-phase artifacts
+and synchronize it. The review message is an index to that evidence, not the
+evidence container. Do not maintain or infer a second gate template in the
+skill. `response.review.presentation` owns every fixed gate label, document
+label, primary connector, and exact decision question. Apply its
+`requiresLocalization` instruction exactly: preserve supplied strings verbatim
+when false, or localize all human-visible presentation strings to its
+`contentLanguage` when true while preserving machine identifiers. Never derive
+gate prose from the report's output language. The Agent supplies only idea
+identity values, one short review focus, selected review links, and
+host-specific link targets in the compact order directed by `response.nextSteps`.
+
+Choose links by gate:
+
+- **Ideal:** `Idea.md` and only substantive Ideal World supporting files. Do
+  not list placeholders, downstream seeds, or `ledger.md`.
+- **Implementation:** always `Implementation.md` and `ledger.md`, plus only
+  substantive Inner World support, key source or test files, durable evidence,
+  or a candidate diff that materially helps the decision.
+- **Deployment:** always `Deployment.md` and `ledger.md`, plus only substantive
+  Outer World evidence or relevant external results.
+
+Give every listed file a host-clickable local link and immutable,
+commit-pinned remote link when available. A local link is only a navigation
+convenience if the checkout has moved. Never use a moving branch URL. If no
+reliable permalink can be formed, provide the full primary commit and
 repository-relative path and explain why.
 
-Follow the host's file-link convention in ordinary assistant Markdown. In
-VS Code on Windows, use an absolute drive path with forward slashes, such as
+Follow the host's file-link convention. In VS Code on Windows, use an absolute
+drive path with forward slashes, such as
 `[Implementation.md](C:/repo/Implementation.md)`; never use backslashes or a
-`file://` URI. Filesystem existence alone does not prove that a tool-owned
-surface can resolve the link.
-
-Synchronization and links make review possible; neither constitutes a human
-decision.
-
-Silvermoon has no approval, acceptance, or abandonment mutation commands.
-After an explicit human decision, reconfirm that it applies to the selected
-idea and exact revision from `whats-next`; change only the corresponding status
-fact:
-
-- ideal approval records `approvedRevision`;
+`file://` URI. Do not put local file links in tool-owned questions or choices.
+
+Deliver the index as a standalone, completed ordinary assistant Markdown
+message and end that turn. Never invoke an interactive decision tool in the
+same assistant turn:
+the host may prioritize its card and hide queued Markdown. Only a later turn
+may open the tool, with one question and choices limited to the exact decision.
+If the user answers the index directly, record that decision without reopening
+the tool.
+If the tool is unavailable, cancelled, or returns no explicit choice, stop
+after one concise wait statement; do not retry it or repeat the gate rationale.
+Do not add lifecycle-policy essays, repeated gate rationale, test summaries, or
+deployment narration to the review message.
+
+For v2 projects, follow [events.md](./references/events.md): observe the exact
+log and primary, use the project-version `event append` command for the
+Agent-owned matching `submit*`, and use it again for `accept*` only after the
+explicit decision. Never infer authorization from a CLI flag, clear decisions,
+or append observations. An acceptance must match the already submitted exact
+revision. Routine state changes use append only. Exceptional history
+maintenance edits the complete `events.jsonl` file directly, then uses ordinary
+Git review and snapshot/history checks; there is no revise or recover command.
+Keep selector, audience, and output language through conflicts and retries.
+
+For v1 projects there is no decision mutation command. After an explicit human
+decision, reconfirm the selected idea and exact revision from `whats-next`;
+change only the corresponding status fact:
+
+- idea acceptance records `approvedRevision`;
 - implementation acceptance records `implementationAcceptedRevision`;
 - deployment acceptance records `deploymentAcceptedRevision`;
 - abandonment or reversal changes only canonical `abandoned`.
 
-Never infer a decision from silence, prose, Git activity, ledger checkboxes, or
-an outer command. Validate a status change with `silvermoon check --worktree`,
-stage it, run `silvermoon check --staged`, commit it separately when practical,
-synchronize it to primary, and reobserve the resulting lifecycle state.
+Validate a status change with `silvermoon check --worktree`, stage it, run
+`silvermoon check --staged`, commit it separately when practical, synchronize
+it to primary, and reobserve the resulting lifecycle state.
 
 Follow [adoption.md](./references/adoption.md) when creating or explicitly
 converting a repository to Silvermoon.
+
+Experimental Copilot adapters are documented in `docs/reference.md` in the
+Silvermoon source repository. Their delivery streams are observations, not
+event history; after uncertain delivery, reobserve the exact project log and
+session before retrying or appending any reply.

package/skills/silvermoon/references/adoption.md

@@ -5,7 +5,7 @@
 Start with a complete diagnosis, even in an unfamiliar repository:
 
 ```sh
-npx silvermoon@<version> whats-next
+silvermoon whats-next
 ```
 
 Default output renders only the self-contained response. Add `--json` only
@@ -15,32 +15,59 @@ when a programmatic consumer needs the complete
 The command may fetch after local readiness passes, but it does not move the
 worktree, index, branches, or named refs.
 
-The target repository may use any language or build ecosystem. If it has no
-root `package.json`, it does not need a package manager, a Silvermoon
-dependency, or `node_modules`. If a root manifest exists, Silvermoon requires
-valid JSON and `devDependencies.silvermoon` exactly equal to
-`^<running-version>`. Follow every command in the setup report, in order; a
-manager-specific remediation may have separate manifest and install steps.
-After the dependencies are installed, register the canonical skill from the
-project-local package:
+Install one Silvermoon runtime for the device or Agent host, independently of
+every target repository:
 
 ```sh
-npx skills add ./node_modules/silvermoon/skills --skill silvermoon --agent universal --yes --copy
+npm install --global silvermoon
 ```
 
-Non-npm repositories register the skill bundled with their running Silvermoon
-installation:
+Register that installation's canonical skill in a personal discovery path.
+Omit `--copy` so the registration remains a link to the installed package:
 
 ```sh
-npx skills add <path-to-running-silvermoon>/skills --skill silvermoon --agent universal --yes --copy
+npx skills add <path-to-global-silvermoon>/skills --skill silvermoon --agent universal --global --yes
 ```
 
-This writes the single repository-local registration at
-`.agents/skills/silvermoon`. Registration and updates belong to `npx skills`;
-Silvermoon compares that path with its bundled canonical skill but never
-overwrites it.
-
-Create `.silvermoon/config.yaml` with the fixed version 1 contract:
+The target repository may use any language or build ecosystem. Silvermoon does
+not read or modify its `package.json`, dependency graph, `node_modules`, or
+repository skill paths. Project readiness depends only on Git, Silvermoon
+configuration, metadata schema, and layout. Runtime identity, latest-version
+checks, and personal skill registration belong to device readiness.
+
+Read a dialogue report's device advisory separately from its project
+observation. A global runtime reuses a successful npm `latest` result for less
+than 24 hours and validates personal discovery links against the running
+package. Missing, broken, or stale links and registry failures require device
+repair but do not turn a valid project snapshot into
+`project-setup-required`. Snapshot-only `check` commands do not perform these
+device checks.
+
+Project observations report every discovered schema-bearing file under
+`observation.schemas`. Validity and current-target readiness are independent:
+a valid v1 file is readable but requires migration before `whats-next` or a
+write workflow continues. `list-ideas` and snapshot-only `check` may read valid
+historical metadata. A future version is never parsed or modified; project
+preparation bypasses the 24-hour latest-runtime cache once and reports the
+runtime freshness outcome.
+
+Silvermoon's own source repository must not depend on its published package.
+Use `node bin/silvermoon.js` from that checkout instead of every `silvermoon`
+invocation below, and refresh its registered skill from the source using
+`pnpm sync:skills`. Its repository-local skill is a development exception for
+unpublished changes and must not be propagated to other projects.
+
+Existing v1 projects remain readable and snapshot-valid, but lifecycle
+preparation requires the declared `project-v1-to-v2` migration. New projects
+use `version: 2` with the
+[event storage and command rules](./events.md); create the canonical
+`events.jsonl` file rather than status YAML and configure a named-primary
+tracking ref before checking. Never convert an existing project by editing
+only its version. Plan the declared edge from the installed runtime with
+`silvermoon-migrate-v1-to-v2 --root <project>`; review its digest before
+applying it as described in the event contract.
+
+The compatible version 1 configuration is:
 
 ```yaml
 version: 1
@@ -60,7 +87,8 @@ silvermoon create-idea
 silvermoon whats-next <ULID>
 ```
 
-`check` validates the selected project snapshot only; it does not navigate
+`check` validates the selected project snapshot (and v2 primary event history);
+it does not navigate
 ideas or check worktree hygiene and upstream. Default `check` validates
 committed `HEAD`, whereas `check --staged` validates the index for pre-commit
 hooks. Its JSON uses all four report projections; `actions` is empty except
@@ -124,10 +152,13 @@ corresponding current world revision.
 
 For a new scaffold, run `silvermoon create-idea`. It generates the ULID,
 four structured documents and alias-less status; it does not stage, commit,
-push, approve, or accept. During initial preparation, complete `Idea.md` while
-keeping the Implementation, Deployment, and ledger placeholders synchronized
-until their lifecycle actions. An Agent may add a concise, unique alias derived
-from the user's request without asking the user to choose a name.
+push, approve, or accept. During initial preparation, complete `Idea.md`,
+replace the Implementation and Deployment placeholders with lightweight first
+versions of no more than three high-level steps and three observable criteria
+each, and mirror their stable IDs and short titles in the unchecked ledger.
+These downstream seeds remain provisional and outside Idea acceptance. An Agent
+may add a concise, unique alias derived from the user's request without asking
+the user to choose a name.
 
 ## Adopting from another layout