---
name: setup
description: Set up Consulting Studio, or check an existing S installation when explicitly asked to run Installation prüfen. Agree scope, inspect actual readers/resources/settings and run one bounded synthetic workflow with an evidence-backed report; no App or MCP required for S.
metadata:
  version: 0.1.8
---

# Set up Consulting Studio

For **Installation prüfen** (also `$setup Installation prüfen`), go directly to
**Check an S installation** below. Offer this entry at the end of
Setup and after an update; a later invocation does not repeat onboarding. It checks
the selected installation, not the source repository or an unrelated plugin.

Use Setup for the **Make it ours** job. Installation does not run Setup automatically.
Use the user's language and reuse readable choices and specific applicable authority
already supplied for this setup. Follow this guided flow and record its choices in
the designated private installation/settings record. Reuse the existing record;
for a confirmed first-use gap, follow the Settings bootstrap below. Do not add a
second intake, configuration registry or tracker.

## Reuse the packaged methods

Read the existing [firm specialization](../org-specialize/SKILL.md) and its
applicable governing/resources through the supported skill reader or local files.
Use its existing procedure for method/settings proposals and adoption; do not
rewrite common methods. For location work, read its packaged
[Workspace Librarian](../org-specialize/references/source/implementation/skills/workspace-bindings/procedure.md),
[binding contract](../org-specialize/references/source/implementation/workspace-bindings/contract.md)
and [storage/lifecycle guide](../org-specialize/references/source/implementation/runtime/storage-lifecycle.md).
These are retained resources in the same plugin. Apply the shared **Deliverable mode
and home** section of the linked storage/lifecycle guide. Select and read the exact required
sections for the chosen workflow, including narrative-shape, evidence-visualize,
publishing-render and publishing-inspect when applicable. If the current reader or installed version cannot
reach a required resource/section, report that exact gap and stop only dependent work;
do not replace the method with remembered instructions or treat an older retained
resource as proof of the current contract.

## Discover standards before asking for missing choices

Before asking which firm policy, index or design to use, actively search the
relevant permitted firm context and read the applicable candidates with current
tools. Start from the selected context, readable settings/index/catalog and known
references; include firm rules, design/template references and storage conventions.
Do not require the user to supply a link to a reference that this bounded discovery
can resolve. A name or search result is only a candidate: read the original and
retain its observed identity, revision, owner, scope and coverage. Reuse compatible
existing references, including design references; do not recreate or overwrite them.
If the relevant context itself is missing, ask only for its understandable name or
link. No unrelated/global search or new access follows.

Report each relevant topic as found-and-read, confirmed missing in the inspected
scope, not found in a limited search, inaccessible, or not checked. Only adequate
bounded inspection plus a responsible person's confirmation that no other rules
apply establishes a gap for a new standard. A limited search, unreadable reference
or unavailable tool proves no absence. Explain the actual coverage/access gap and
ask one focused question, for example: "Do you already have rules for naming
project documents, perhaps somewhere else?" Reuse an answer already supplied.
Do not repeatedly ask about found rules. Multiple applicable candidates or
conflicts need an owner choice; never guess the governing reference. A required
unread reference blocks its application, not independent permitted preparation.

## Offer small proposals for confirmed gaps

For confirmed gaps, offer a **proposed starting point**, not a firm fact or a list
of mandatory intake fields. Select only what the chosen workflow needs and show
existing rules alongside the few still-open decisions. For example:

| Missing topic | Optional starting point to discuss |
| --- | --- |
| Storage | Reuse suitable authorized homes; reference central designs/templates and keep each engagement's confidential material in its own dedicated Shared home by default. A chat-only route can remain transient. This proposes no new Space, fixed tree or access grant. |
| Naming | Use a short recognizable project reference and document purpose; where supported, add the exact version. Translate an agreed rule only to the finite naming parts supported by the current schema. |
| Versions and status | Keep identifiable revisions and human changes; distinguish draft, reviewed, released and accepted. A save or generated revision does not advance these states automatically. |
| Responsibility | Propose the relevant roles: engagement lead for project work and a firm settings/design owner for shared rules. Ask who will take an unresolved role; invent no person, current owner or approval. |

Ask whether to keep, change or defer the specific proposal; do not make every row a
required question. Missing storage/naming/override rules do not prevent a labelled
read-only proposal in chat or independent ordinary work. Existing design rules can
be reused while unrelated gaps remain open. Do not invent a policy identity,
revision, owner, firm rule or an organization-wide permission for project overrides.
A proposal is not an effective reference. Only an attributable responsible human
decision bound to the exact proposal and scope can legitimate adoption through
org-specialize; saving configuration, provisioning and rights remain separate
supported authorized effects with their required confirmation and readback.
Do not call `propose_workspace_setup` until its required source, policy, target and
revision fields are genuinely resolved; never fill them with suggested facts.
On a repeated Setup run, freshly read existing rules, decisions and prior effects;
reuse them and propose only the remaining gaps. No duplicate standard, settings
record or home, and no silent automatic adoption follows.

## Discover, choose and agree the smallest useful environment

1. Inspect bounded account/workspace and home metadata, available apps, actual
   connections/accounts, configured actions and current-runtime exposure. Inspect
   relevant existing settings/index/catalog, homes and design/template references
   supplied or selected by the consultant. When identities are missing, discover
   candidates only in the relevant permitted context; do not scan unrelated projects
   or private content. Separate observed capability, owner-reported practice and
   unknowns. A declaration, connection, provider name or plan proves no operation.
2. Follow Make it ours in order: relevant workflows/methods and desired output forms;
   existing templates, language/design and quality/approval rules; then necessary
   storage and app actions. Offer inspected provider/account/action choices for the
   consultant to select. Mixed layouts are valid: source, settings, entity and output
   homes can use different supported providers. Reuse adopted versions and compatible
   homes; the five logical areas impose no fixed folder or Space tree. A full firm
   profile is not required for ordinary use. Ask only missing consequential choices.
   If dependent tailoring needs geography, client breadth or service focus, obtain
   those choices or explicit adoption of an exact existing target brief. Historical
   profiles, interface language and examples select no defaults.
   Keep geography, client industry/segment breadth and consulting service/function
   separate in the existing domain brief and installation/settings fields. Missing
   choices stay unknown. Map applicable terminology, evidence dimensions, methods
   and output forms to affected skills, exact references/versions, owners and
   candidate/adopted status through org-specialize. Clarify conflicting choices or
   unread mandatory references only for dependent tailoring; ordinary neutral work
   can continue. A labelled example never adopts its target or requirements.
3. Show **current state, concrete target layout and exact proposed changes** together:
   selected workflow/output types, resource identities/parents, owners, context,
   audience, actions, initial content/references, reuse/create decisions and gaps.
   Keep sources and output destinations separate. Unreadable or denied homes are
   not absent. Reconcile prior effects by actual identity/content before retries or
   resumption; do not create duplicates. The consultant agrees the target and changes
   before provisioning. Existing specific authority can cover the selected effects;
   obtain only missing decisions and actual required action-time confirmations.
4. For each selected workflow/output type, settle chat-only/transient versus retained
   mode. In existing binding/destination/authority fields, record authoritative home,
   owner/audience/context, supported save/update/readback, current authority, effective
   form/content/design references, standing retention scope and configuration revision.
   An entity's authoritative home outranks an unrelated personal preference; a source
   home chooses no output home. An explicit chat-only request overrides standing
   retention. Read-only queries create no unsolicited retained copies. A retention
   choice alone proves no save. A synthetic example supplies no real-client data
   admission, retention authority or production grant.
5. For improvements, discover supported issue trackers and **recommend issue-based
   tracking by default**. Confirm the installation's actual tracker/project/destination,
   owner/triage, audience, permitted material and filing authority; a Page backlog is
   an explicit alternative. Configure the existing `feedback-drafts` role and record
   filing versus review-first preference with its revision in existing settings.
   No forced GitHub dependency or silent fallback. Do not automatically create
   issues/projects or migrate an existing backlog; those need a separate concrete
   supported request and applicable authority. A future useful issue records the
   problem, desired outcome, acceptance criteria and permitted evidence, with a
   linkable lifecycle to later PRs where actually supported. Filing implies no
   adoption, implementation or release.
6. Apply only the agreed supported operations under applicable authority. Reuse
   compatible homes and create only selected supported missing structure. Preserve
   accepted records/settings, wiki content, human notes/dissent, issued work and
   confidential boundaries.
   Home creation, settings adoption and configuration/binding persistence are separate
   effects: save and read back configuration separately from home creation, including
   its effective revision. Use the one designated private checkpoint/updater, or the
   existing explicitly selected owner-retained route. Keep actual installation
   locations, private settings, design assets and resource IDs in that authorized
   configuration home, outside reusable methods. Missing apps/actions,
   connections or grants remain owned gaps; do not expand sharing, connect/install
   apps, handle credentials, send business messages, publish, delete or schedule.

## Connect the selected project's existing records

For project setup, apply **Project record maintenance** in the binding contract
already linked above. Read the existing project home, baseline, partial plan and
human notes before proposing content. Show only the relevant existing business
records and the smallest missing sections/references: purpose, trigger, responsible
skill, accountable owner or unknown, authoritative original/revision, actual state,
project navigation and maintenance occasion. A small task needs no empty project
tree. Reuse existing identities and central references; the project index navigates
to originals rather than keeping another baseline or current-synthesis list.

For example, inspect the existing contextual Party/Stakeholder references and
`baseline.stakeholders`, with permitted exact Sales evidence. Propose a missing
roles section only when needed; a table suffices. Unknown sponsor or decision
authority remains unknown. Confirm consequential unresolved authority with its
owner; a job title proves no delegation. Preserve private Sales evidence at its
original and invent no people, influence scores or second stakeholder registry.

Use the existing supported creation/reuse/index procedure for covered additions,
with separate content, navigation and binding readback. A saved original with an
unfinished index update stays saved with navigation open. Reconcile its exact
identity and current index before resuming only the missing authorized step;
never create the original again. Ordinary completion hands new/changed records
to the existing maintenance procedure only when reference work is needed. This
creates no background task, automatic skill call or substantive acceptance.

## Bootstrap and recover durable Settings

This is the common rule for the App and Skills-only variants. A private Settings
Page or another observed supported native settings home is sufficient; no dedicated
Studio database is required for this record. Settings storage, an attributable owner
decision, discovery bindings and later-session application are separate facts.

1. **Discover before creating.** Freshly read the selected context's designated
   settings/installation record, relevant index/catalog, supplied direct locator and
   prior setup effects where present. With no known locator, use the Librarian's
   generic `Consulting Studio Start Index` discovery contract first; no specific
   Settings title or ID is needed. Follow bounded discovery above and reuse a
   compatible record. A limited search, missing tool, unreadable record or denied
   access proves no absence. Multiple candidates or conflicting current settings
   require the responsible owner's resolution; do not overwrite or create a parallel
   record. Continue independent permitted work while dependent settings work waits.
2. **Offer a concrete first home.** For an adequately inspected, owner-confirmed
   missing Settings record, actively offer the smallest suitable private Settings
   Page through currently available Pages actions. Inspect the actual target/parent,
   owner, effective audience and supported create/read/update operations first; a
   Page title or nesting proves no privacy. If Pages is unavailable, offer another
   inspected supported native settings route. If none is available, return the exact
   proposed content and owner-mediated save/read steps as an unsaved handoff. Do not
   stop at "settings are not saved" without a concrete next step. Access denial is
   not unavailability: stop the denied action without a replacement or silent fallback.
3. **Confirm the exact settings effect.** Show target/provider/parent, title, scope,
   accountable owner/updater, audience, exact initial content/references, proposed
   status and supported operations together. Include only agreed choices and actual
   observed reference identities/revisions; unresolved fields stay unknown. Keep
   candidate and adopted settings explicit, with the attributable owner decision
   bound to the exact content and scope through org-specialize. Reuse valid specific
   authority, but obtain missing confirmation before writing. Approval of a project
   Page alone does not authorize a Settings write, owner adoption or index creation/edit.
   Prepare one designated record, not another tracker or a copy of client content.
4. **Create once and read independently.** Perform only the confirmed supported
   create/settings operation. Retain returned identity/locator and operation outcome;
   then reopen that exact identity through a separate native read. Compare meaningful
   agreed content, scope, status, owner/audience and actual revision where available.
   Never invent an ID, URL or revision. A create response alone is saved-unverified;
   missing or mismatched readback leaves completion open. A conflict requires a fresh
   read and a newly agreed guarded change preserving human edits/dissent. For an
   unknown create outcome, reconcile the same attempt by returned identity or bounded
   exact-reference inspection before any retry. Unresolved or ambiguous effects
   prohibit another create; absence from search alone does not settle occurrence.
5. **Offer and test the start index and registration.** Explicitly offer the exact registration
   in a suitable existing private index/catalog or supported discoverable native
   settings entry: actual locator/identity, owner, workspace, context, purpose, scope
   and observed revision. Apply the Librarian's generic searchable start-index label
   and contract marker so a fresh chat needs no private title or ID. Reuse an existing
   compatible index/section. If bounded inspection plus owner confirmation establishes
   that no suitable start index exists, concretely offer its smallest private native
   Page/section with that generic label, matching scope/owner/audience and the exact
   Settings reference. Index creation and Settings registration each require covered
   confirmation before their supported writes and separate readback; Settings storage
   alone does not authorize either. This reuses the Personal Index/Shared Catalog
   roles, not a second Settings record or progress tracker.
   Show the exact addition and audience; obtain its specific
   authorization before editing. Preserve existing content and separately read back
   the binding/revision. Home readback is not binding readback. Invoke the packaged
   Librarian's bounded discovery from the intended normal entry without handing it
   a specific index/Settings title or locator; start from the generic contract and
   freshly read and compare the exact record found. If this
   cannot run, record discovery as untested with the precise missing operation.
   With no reliable supported discovery route, offer the actual direct locator as a
   manual fallback for the owner to retain; do not present repeated link entry as the
   normal route. A start index is not a prerequisite for saving Settings; offer it
   to enable reliable discovery, not as a mandatory tree. A direct locator alone
   proves neither discovery nor later-session application. Keep private settings out
   of broader project/navigation audiences.
6. **Report the separate states.** State Settings storage/readback, owner decision
   documented or pending, discovery bindings checked/missing/not checked, and
   later-session application checked or untested. Plan a separate fresh-session
   probe through activated Consulting Studio/Librarian without a supplied Settings
   locator or prior-chat contents. It must discover the registered entry, freshly
   read the record and match acting user, workspace, context, purpose, scope and
   effective rights before applying only applicable adopted settings. Without an
   actual fresh-session observation, later-session application stays untested. A
   foreign context or colleague inherits no choices or grants. No automatic global
   effect, method rewrite or automatic adoption follows; there is no autoload promise
   in arbitrary chats or without the relevant skill/workflow invocation.
   If no durable progress record exists yet, return the observations/locator for the
   owner to retain; do not assume that this handoff has itself been saved.

**App branch:** additionally inspect actual Studio configuration and any selected
project adoption separately through available supported read routes. A Settings
Page neither saves Studio/D1 configuration nor adopts a project. Any missing App
operation blocks only that dependent step; native Settings work can proceed within
its own authority. **Skills-only branch:** no Studio App, MCP, D1 or studio-resume
operation is required or inferred. Use the same native Settings and Librarian
discovery procedure; manual locator recovery is a fallback, not the normal entry.

## Establish the selected Pages information architecture

When the agreed setup includes Pages structure, read and execute the packaged
[Pages setup procedure](references/pages-setup.md). It covers fresh bounded discovery,
reuse and missing-part proposals, separately authorized additive provisioning,
interruption reconciliation and independent identity/hierarchy/link/content readback.
Apply it to existing placeholder entry/index pages and project homes as well as
missing ones. Configuration adoption in Studio/D1 alone does not perform this work.
Read the procedure before presenting the exact proposal; keep actual operations,
configuration persistence, ordinary use and owner acceptance separately evidenced.
Simple Library saving requires no Pages tree, Studio project or complete Setup.
Library file storage, Studio/D1 workflow state and Pages originals remain distinct.

## Offer an optional workflow check

Offer three choices: **skip the workflow check for now**, **use permitted supplied
content**, or **try a clearly labelled synthetic example**. Reuse an explicit
choice already made for this setup. Skipping does not block normal use or the
agreed supported setup work; record the workflow check as not run, with the
remaining checks visible. Setup imposes no product-wide synthetic-only mode.
Normal projects start empty and use user-provided or authorized content. Never
automatically insert example sources, requests or results into normal projects,
homes, settings or knowledge. An example is neither a firm default nor real evidence.

For an optional synthetic run, offer the small reusable
[optional synthetic example](references/optional-synthetic-example.md) or a
compatible explicitly selected existing test dataset. Read that resource only when
the example route is selected. Agree its bounded request, success criterion and
chat-only or separate clearly labelled test destination before any effects. Keep
the synthetic designation visible in input, request and result lineage, including
on resumption; never relabel a historical fixture as real. Inspect earlier effects
before retrying and prefer a compatible existing test record. No automatic copy,
retained write or live operation follows from reading the resource.

For permitted supplied content, use the selected ordinary workflow under its actual
source, audience, use and retention authority; ask only for missing applicable
authority or policy. Existing valid arrangements can suffice. Synthetic example
success grants no real-client admission or retention acceptance. If material is
not authorized, stop only its dependent work and offer permitted preparation or
the optional synthetic route. Mark any prepared output unaccepted.

If a workflow check is selected, agree one small useful ordinary request and success
criterion in the selected scope. Offer a scoped ordinary presentation workflow when
the consultant selects presentations; a generic test note does not substitute for
that choice. Apply the following checks to the selected workflow only.

For a presentation, reuse its actual audience/purpose, permitted content and effective
design/template references. Apply publishing-render's explicit question: **"Would you
like me to use narrative-shape to shape this for your audience before I produce it?"**
Use the user's language and wait for this request's explicit yes or no before creating,
editing, rendering or exporting. Silence, supplied story or remembered preference is
no answer. Reuse an actual answer on continuation of the same request; a new request
needs its own question. On yes, apply narrative-shape with the consultant: develop
and settle the central message and story arc through their actual feedback before
full production. Reuse an established direction; explicit independent drafting stays
labelled with its delegation and assumptions. On no, preserve the supplied argument,
emphasis, sequence, qualifications and dissent. For a substantive report/presentation workflow, explicitly apply evidence-visualize
before production, validate reusable figures or record a justified text/table-only
outcome, and coordinate with the actual narrative choice. Integrate selected figures
beside their arguments with visible captions/sources/qualifications and static export
fallbacks; inspect every selected final figure in every requested format. Then render
and inspect the exact artifact through the supported route. An unavailable required method blocks dependent
production; do not silently switch routes or call an outline a finished presentation.

For retained output, use the actual agreed output home and present exact proposed
content/destination for any required write confirmation. Save through the supported
operation, then reopen the returned identity through a separate read and compare
meaningful content/revision. Retain actual save/readback receipts. Save/read back
configuration separately when selected; creating an output or home does not establish
configuration persistence. A local draft or create response alone proves no reopening.
For an explicit chat-only/read-only selection, perform no unnecessary retained write;
state retention/save/reopen as not applicable with its reason. If a retained setup
check was required, an unsaved draft cannot pass it.

Return the current/target layout, choices, effective configuration revision, reused
references and, for a selected workflow, exact output home/identity/version/state,
actual operation/readback receipts and result link, plus each gap's owner and smallest
next action. For a skipped check, report no workflow output or save/readback and
keep its status not run; do not invent an output identity or acceptance. State omitted
retrieval, rendering, semantic/visual/reader checks, colleague access and continuity
honestly. Claim discovery, provisioning, readback or workflow success only from
actual observations; obtain the owner's separate acceptance. Keep prepared, saved-unverified, saved-and-reopened,
owner adoption and acceptance separate. A blocked save remains blocked; continue
independent permitted preparation without claiming completion. Use the existing private
installation record, not a parallel tracker. Stop after this agreed onboarding scope;
other workflows, WA adoption and real-client admission need their own applicable checks.

## Check an S installation

Procedure **S-SESSION 0.1.0** is a customer-invoked, selected-workflow check. S needs
no Studio App, MCP, GUI, D1, WA, Pages tree or persisted Settings. Run through the
actually available skill/resource readers and ordinary skill use; no Python helper
or developer fixture is a customer prerequisite. Use the report contract below in
the existing private installation/settings record. Without authorized storage,
deliver it unsaved in chat. Reading this procedure authorizes no live write.

1. **Agree scope before checks.** Reuse the current request and readable installation
   record; ask only for missing consequential choices. Record scope ID/revision,
   agreement/actor/time, acting user, account/workspace, execution surface/session,
   expected plugin/release/configuration identities (or unknown), intended workflow,
   exact expected skills and task-required resource sections, useful-result criteria,
   and chat-only versus a selected retained-storage leg. Use current supported
   metadata/read routes; distinguish an owner-reported identity from an observation.
   Select these required checks: `context`, `identity`, `resources`,
   `settings_inspection`, `workflow`; add `retained_storage` only when selected.
   Record applicability and exclusions now. Preserve this scope with the report;
   a later changed scope needs a new revision/agreement, never a green rewrite of
   the old run. An unknown expected or observed installation identity blocks
   installation confirmation; a useful workflow may still pass on its own.
2. **Inspect this surface.** Inspect the actual exposed reader/tool schemas and
   supported skill discovery/catalog where available. Compare expected and observed
   skill/resource identities and coverage. There is no assumed skill-enumeration
   API. A visible label, manifest/version declaration, tool listing, source hash or
   import receipt proves neither freshly loaded instructions nor executed behavior.
   Keep unknown package identity and partial catalog coverage explicit. Name each
   selected resource/section, supported reader request, returned identity/revision,
   output evidence/ranges and truncation/continuation gaps. Read required sections
   before dependent use. Unavailable readers are BLOCKED; attempted wrong/stale
   content is FAIL; unattempted reads are NOT_RUN. Do not silently replace an
   unread method with remembered instructions or a generic answer. Selected-section
   coverage establishes no full-catalog or all-35-mode pass.
3. **Inspect existing Settings without forcing setup.** Use the packaged Librarian
   discovery contract in the permitted context, reusing its existing record and
   current access checks. Read an applicable existing Settings original and revision;
   distinguish adopted choices from proposals. A bounded adequately inspected and
   owner-confirmed absence can pass `settings_inspection` for neutral chat-only
   use: record **unconfigured**, with no configuration-persistence claim. Limited
   search, ambiguity, denial or an unreadable current record stays BLOCKED for this
   check; it is not evidence of absence and permits no substitute record. Independent
   neutral preparation can continue. Do not create Settings, register an index,
   adopt a configuration or require Pages merely to make this check green.
4. **Run one useful synthetic workflow.** Agree a small chat-only task, its selected
   method and criteria; use the source-free option in the already packaged
   [synthetic example](references/optional-synthetic-example.md) if useful. This is
   actual ordinary method use on the selected installed surface, not replay of a
   repository test. Read its required instructions/resources through current readers,
   then execute and inspect the exact versioned output against the agreed criteria.
   Retain output and inspection evidence separately. A source-test simulation stays
   labelled as such and cannot confirm an installation. A skipped task is NOT_RUN
   and leaves this verification incomplete, while ordinary use remains possible.
5. **Optional retained-storage leg.** Before any save, use the existing Librarian/
   deliverable-home conventions to inspect the exact synthetic content/version,
   destination/provider/parent, owner/audience/context, effective principal, current
   authority and supported save/reopen operations. Present that exact effect and
   obtain its applicable confirmation. A chosen retention mode alone is no consent.
   Save once; separately reopen the returned exact identity and compare meaningful
   content, identity and actual revision where exposed. If revision is not exposed,
   state that limit; do not invent it or pass a criterion that requires revision.
   A create echo or local bytes are not independent readback. Missing consent or
   operation is BLOCKED, mismatch is FAIL, and a save with no readback is incomplete.
   For an uncertain outcome, inspect the same attempt by returned identity or bounded
   exact-reference reconciliation before any retry; unresolved effects prohibit
   another save. No automatic cleanup/deletion, permission change, repair, new home
   or forced storage setup. Saving this report is a separate authorized effect,
   never a second test save or an automatic side effect of the check.
6. **Return the report and next action.** Each included check is PASS, FAIL, BLOCKED
   or NOT_RUN with expected/observed result and actual evidence. Excluded checks
   retain a reason and NOT_RUN; they do not count as passes. Missing required evidence,
   stale/mismatched identities, incomplete reads and uncertain effects prevent scope
   PASS. Report FAIL for a demonstrated mismatch, otherwise BLOCKED for a required
   unavailable prerequisite/evidence, otherwise NOT_RUN for unfinished required work.
   Only all required PASS with actual native observations permits **Installation
   verified for [exact scope/version/user/environment]**. Report base workflow
   usability separately from configured retention, and expose unverified identities.
   Keep customer acceptance **pending** until an actual attributed decision:
   accepted, accepted with reservations, or correction requested, bound to this exact
   report/scope/version/actor/date. Acceptance never changes technical statuses.

### Versioned verification report

Keep each run/revision and earlier failures/notes in the same existing record;
reruns reference the previous report and newly observed evidence. An unavailable
record blocks dependent resumption, not authority to create a parallel registry.
No authorized report save means **unsaved delivery** with an owner-retained handoff.

| Report field | Required meaning |
| --- | --- |
| Identity and time | Report ID/revision, procedure S-SESSION 0.1.0, previous-report reference or first run, scope ID/revision/agreement established before checks, start/completion time |
| Context and pins | Acting user, account/workspace, surface/session; expected and observed plugin/release/resource/configuration identities, unknowns, attributable evidence and freshness |
| Coverage | Exact selected skills/required sections and actual reader/tool coverage; full catalog partial/unknown; Settings read/unconfigured/unresolved and applicability |
| Check rows | ID, required/applicable or excluded with reason, expected, observed, PASS/FAIL/BLOCKED/NOT_RUN, evidence references, gap owner and smallest next action |
| Output and effects | Synthetic request/result version, criteria/inspection; chat-only or exact confirmed destination/save/separate readback, revisions and uncertain effects |
| Technical result | Scope status and confirmation only under step 6; base usability and configured retention separately; actual observations versus source simulations |
| Decision and delivery | Separate attributed customer acceptance or pending; report saved/read-back versus unsaved, with actual locator only when observed |

Always exclude from S-SESSION with explicit reasons: M App/MCP and M-HOST/M-DIST
qualification; independent S-DIST fresh installation, update and recovery; full
catalog/standard-mode coverage; fresh-session continuity; colleague access; general
real-client readiness and unresolved platform export/restore/retention contracts.
These remain NOT_RUN under issue 228's separate profiles; this first slice closes
none of them. A selected required retention capability cannot later be relabelled
excluded because it failed. One scoped session proves no broader installation or
customer acceptance.