feat(engine): separate application and authoring workflows

.agents/skills/standards-engine/SKILL.md

@@ -1,9 +1,13 @@
 ---
 name: standards-engine
-description: Navigate, analyze, and author this repository's coding standards through the Standards Engine. Use when an agent needs to route or read standards, inspect related policies, propose or revise a standards change, review or apply a proposal, verify standards, or recover an application; do not use for ordinary source-code edits.
+description: Maintain this repository's coding standards through an authoring-purpose Standards Engine connection. Use when an agent needs to route or read standards, inspect related policies, propose or revise a standards change, review or apply a proposal, verify standards, or recover an application; do not use for ordinary source-code edits.
 ---
 
-# Standards Engine
+# Standards Engine Authoring
+
+This skill is maintenance material for standards authors. Ordinary application
+agents use their application-purpose tool catalog and approved guidance, rather
+than loading this authoring skill.
 
 Use the generated public Interface. The Engine is the sole writer of standards
 Markdown, metadata, supplementary projections, SQLite state, and local Git
@@ -12,7 +16,7 @@ Engine request into direct file, SQL, or Git mutations.
 
 ## Use The Agent Tools
 
-Use the `standards-engine` MCP tools. The client supplies each operation's
+Use the `standards-authoring` MCP tools (or the host's explicitly configured authoring-purpose registration). The client supplies each operation's
 current input schema; call the named tool directly with structured arguments.
 Tool-name prefixes vary by client; operation names match the Engine contract
 (for example, `route`, `read`, and `propose`).

.agents/skills/standards-engine/references/authoring.md

@@ -46,6 +46,7 @@ The closed edit variants are:
 
 - `create-standard`
 - `revise-standard`
+- `register-policy-unit`
 - `revise-policy-unit`
 - `move-policy-unit`
 - `retire-policy-unit`
@@ -57,12 +58,17 @@ The closed edit variants are:
 - `put-routing-fact` / `remove-routing-fact`
 - `audit-policy-unit`
 - `rewrite-navigation-index`
+- `put-provenance` / `retire-provenance`
+- `approve-application-content` / `withdraw-application-content`
+- `revise-operational-artifact`
 
 Use the `propose` tool definition for their current exact fields. In
 particular:
 
 - whole-standard body changes must include companion policy-unit semantic
-  decisions when registered policy meaning changes;
+  decisions when registered policy meaning changes; `scope_updates` supplies a
+  complete registered-scope disposition when a whole-module rewrite changes
+  headings or explicitly preserves meaning across structural changes;
 - preserved policy meaning uses the schema's preserve variant, while changed
   meaning states accepted and proposed semantic revisions plus intent;
 - relationship changes state their meaning, applicability, evidence owner,
@@ -95,6 +101,41 @@ sufficiency, or successors from prose. If the user has not decided required
 meaning, stop at the typed rejection or ask for that decision instead of
 manufacturing closure.
 
+## Register A Scope In An Existing Standard
+
+Use `register-policy-unit` to bind a selected existing scope to a fresh stable
+policy ID. Supply the existing canonical `standard` and the schema's
+`policy_unit` declaration: ID, heading chain, revision one, explicit intent,
+aliases, predecessors and successors. Registry paths and generated bindings
+remain Engine-owned. The declaration uses the same validated policy shape as
+`create-standard`.
+
+Registration preserves the standard's body. It supports both previously
+unmapped modules and owners that already contain policy units, preserving
+existing identities, aliases and tombstones. Select one uniquely resolved,
+non-overlapping scope and an available identity. Existing lifecycle and lineage
+validation remains authoritative.
+
+A coherent change set may revise a module, register selected additional scopes,
+and add relationships and provenance for those scopes. Module and existing
+policy content changes run first; registrations are validated together before
+consumer relationships and final supporting bindings. `scope_updates` describes
+the policies registered before those new registrations. Input edit order does
+not change this staging.
+
+Registration establishes an identity, not audited coverage. Resolve the actual
+consumer, impact and coverage obligations before review and publication. A
+rejected registration leaves the current proposal revision and accepted source
+unchanged. Use the returned status and current contract for recovery or revision.
+
+After installing interface 33, restart the Engine process and refresh the client
+catalog. Reopen preserved work with `workflow_status`; use `resume` only to select
+its explicit current revision when needed. A previous review remains historical
+evidence, while changed candidates receive current analysis and affected review.
+`resume` selects a proposal revision; it does not promise to rebase an old source
+snapshot. Follow any returned stale-base disposition rather than editing a store
+or carrying old readiness onto changed material.
+
 ## Navigation Index Correction
 
 For a legacy navigation correction, call `read` with target
@@ -184,3 +225,13 @@ in the evidence record; unregistered text still receives ordinary whole-artifact
 change analysis. Use `retire-policy-unit` instead only when the normative policy
 itself is being retired. Maintenance prunes claims against the final candidate's
 requirements, including claims invalidated by the registration changes.
+
+## Purpose-separated supporting content
+
+Use the [implementation operation map](../../../../tools/standards_engine/PURPOSE-SEPARATION.md#authoring-operation-map)
+for the code-to-content handoff. Read operational aids to obtain their captured
+authoring target. Submit provenance content and an explicit exposure decision
+in the same coherent change as applicable; the Engine binds final candidate
+content. Provenance-only maintenance retains unchanged normative revisions.
+Application eligibility starts empty and becomes active only after reviewed
+publication, not after merely creating a draft.

.agents/skills/standards-engine/references/environment.md

@@ -1,102 +1,100 @@
 # Agent Tool Connection
 
-Use Python 3.11 or 3.12. Prefer an existing isolated environment that was
-installed from `tools/standards_contracts/requirements.lock` with hashes
-enforced.
-
-When no such environment exists, create one outside the repository:
+Use Python 3.11 or 3.12 and an isolated environment installed from
+`tools/standards_contracts/requirements.lock` with hashes enforced. Preserve the
+pins and select the environment explicitly:
 
 ```bash
-python3 -m venv /tmp/coding-standards-engine
-/tmp/coding-standards-engine/bin/python -m pip install \
+python3 -m venv /absolute/path/to/engine-environment
+/absolute/path/to/engine-environment/bin/python -m pip install \
   --require-hashes --only-binary=:all: \
   -r tools/standards_contracts/requirements.lock
 ```
 
-Use that environment’s Python executable in the MCP server configuration. Dependency installation may require network or package-cache
-authorization; request it when required. If the locked environment cannot be
-created, report the dependency boundary as unavailable. Do not install into the
-repository, relax hashes, choose alternate versions, or implement a fallback
-validator.
+Dependency installation requires the operator's available package cache or network
+and its relevant authorization. An unavailable locked environment leaves that
+qualification pending rather than selecting replacement versions.
 
-## MCP Stdio Server
+## Purpose-specific MCP registrations
 
-Register a local stdio server named `standards-engine` in the agent client's
-MCP settings. Replace the absolute paths below with the installed interpreter
-and repository checkout. `PYTHONPATH` selects the code; `--repo-root` selects
-the standards repository, independently of the client's working directory.
+Choose purpose in host configuration. Application agents receive the application
+registration; standards maintainers use a separate authoring registration. Use a
+new application session after authoring. The Engine cannot erase prior context.
 
 ```json
 {
   "mcpServers": {
-    "standards-engine": {
-      "command": "/tmp/coding-standards-engine/bin/python",
-      "args": [
-        "-P", "-m", "tools.standards_engine.standards_engine.mcp",
-        "--repo-root", "/absolute/path/to/Coding-Standards"
-      ],
+    "standards": {
+      "command": "/absolute/path/to/engine-environment/bin/python",
+      "args": ["-P", "-m", "tools.standards_engine.standards_engine.mcp", "--repo-root", "/absolute/path/to/Coding-Standards", "--purpose", "application"],
+      "env": {"PYTHONPATH": "/absolute/path/to/Coding-Standards"}
+    },
+    "standards-authoring": {
+      "command": "/absolute/path/to/engine-environment/bin/python",
+      "args": ["-P", "-m", "tools.standards_engine.standards_engine.mcp", "--repo-root", "/absolute/path/to/Coding-Standards", "--purpose", "authoring"],
       "env": {"PYTHONPATH": "/absolute/path/to/Coding-Standards"}
     }
   }
 }
 ```
 
-For Codex, the equivalent entry in `config.toml` is:
+These are separate intended audiences, not two registrations every agent should
+receive. Translate the command, arguments and environment to the client's actual
+configuration format. Reconnect after the breaking contract update. Verify the
+application catalog contains navigation and the authoring catalog contains the
+required maintenance workflow. `--advanced` adds only operations admitted by the
+configured purpose.
+
+The local server remains synchronous MCP stdio with protocol `2025-11-25`;
+requests execute serially and immutable Engine handles survive reconnection.
+The current implementation is 0.2.0 and Engine interface 31. No network listener,
+paid model turn, remote publication or extra server dependency is introduced.
+The existing local authoring authorization adapter is owner-operated and
+always-allow; explicit user authorization still governs requested changes.
+
+The canonical checkout, store and private logs belong behind the host boundary.
+An application agent with separate filesystem or database access could bypass
+Engine-mediated exposure. This release supplies neither OS sandboxing nor a
+remote multi-user permission service.
+
+## Bootstrap and cutover
+
+New automatic snapshots read accepted local `main`. The code release initially
+contains empty application-approval and provenance manifests. Application reads
+therefore return a bounded unavailable result until the separate content work
+reviews and publishes the required material. Authoring can read the unchanged
+standards once the code candidate is integrated into accepted main.
 
-```toml
-[mcp_servers.standards-engine]
-command = "/absolute/path/to/engine-environment/bin/python"
-args = ["-P", "-m", "tools.standards_engine.standards_engine.mcp", "--repo-root", "/absolute/path/to/Coding-Standards"]
-env = { PYTHONPATH = "/absolute/path/to/Coding-Standards" }
-tool_timeout_sec = 600
+Use a disposable clone with candidate `main` for pre-merge qualification. Preserve
+active installed proposals and recovery obligations before cutover. Old Analysis
+records/captures outside the new supported contract are explicitly unsupported;
+there is no automatic store deletion or conversion. See the complete
+[implementation contract and cutover guide](../../../../tools/standards_engine/PURPOSE-SEPARATION.md).
+
+## Reference CLI
+
+The same purpose boundary applies to list, schema, example and invocation:
+
+```bash
+PYTHONPATH=. /absolute/path/to/engine-environment/bin/python -P \
+  .agents/skills/standards-engine/scripts/invoke.py \
+  --purpose application --list
+
+printf '%s\n' '{"target":"core"}' | \
+  PYTHONPATH=. /absolute/path/to/engine-environment/bin/python -P \
+  .agents/skills/standards-engine/scripts/invoke.py \
+  --purpose application read
 ```
 
-Use a persistent isolated environment for an ongoing installation; `/tmp` is
-suitable for a temporary trial. The longer call timeout accommodates proposal
-verification and application. See [Codex MCP configuration](https://learn.chatgpt.com/docs/extend/mcp?surface=cli).
-
-Client configuration formats differ; preserve the command, arguments, and
-environment when translating these examples. Reconnect the client after
-registration or an Engine contract update. Confirm that `route`, `read`, and
-`propose` are available before starting a standards workflow.
-
-The server supports MCP protocol `2025-11-25` over newline-delimited stdio,
-with initialization, ping, tool discovery, and tool calls. It needs no additional
-Python dependencies. It runs requests serially and opens the durable Engine
-facade for each call; snapshots and proposal handles survive reconnection.
-Only protocol messages go to stdout; diagnostics go to stderr. No network
-listener or remote publication is introduced.
-
-Tool schemas are derived from the generated Engine contract, with only reachable
-definitions included. Domain results are preserved as `structuredContent` and
-JSON text for client compatibility. Rejections set `isError`; pending and
-recovery-required states remain typed domain results. Transport failures are
-errors with unknown domain outcome, never permission to retry a mutation.
-
-This is the existing owner-operated local always-allow authorization adapter.
-Connecting the server exposes the full authoring interface as well as reading;
-user authorization for the requested operation still governs agent behavior.
-The server does not supply semantic decisions or implicit review approval.
-
-For debugging without an MCP client, run the existing `scripts/invoke.py`
-transport from the repository root with `PYTHONPATH=.`. Its `--list`, `--schema`,
-and `--example` options remain available; routine MCP use needs none of them.
-
-Protocol references: [tools](https://modelcontextprotocol.io/specification/2025-11-25/server/tools),
-[stdio transport](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports),
-and [lifecycle](https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle).
-
-## Advanced Native Operations
-
-The default catalog exposes 15 focused tools. Add `--advanced` to the server
-arguments and reconnect when native snapshot administration, accepted-snapshot
-Analysis, verification preflight, or evidence maintenance is required. That
-catalog exposes all supported generated native and focused operations. The
-reference CLI also retains all native operations; there is no automatic fallback
-from a rejected focused call to a native mutation.
-
-Workflow contexts reference existing immutable revision, analysis, or readiness
-records. Reconnection requires no transport session recovery or context cache.
-`workflow-result` preserves the native outcome and provides Engine-derived next
-operations. A rejected nested outcome sets MCP `isError`; pending or recovery
-outcomes retain their explicit status.
+Use `--purpose authoring` only in the authorized maintenance environment. Inspect
+returned domain outcomes; CLI exit zero means the structured invocation completed,
+not that a pending claim or rejected operation was accepted. Malformed/unsupported
+CLI selection exits with a bounded error.
+
+## Client qualification
+
+The real stdio/CLI tests use actual processes and SQLite. The optional official
+MCP SDK harness requires the SDK in a separate client environment and the locked
+Engine Python supplied through `--engine-python`. The optional Codex test uses
+`--server standards-authoring` (or the actual configured authoring name) and does
+not start a model turn. These checks do not certify the content's editorial quality.

.agents/skills/standards-engine/scripts/invoke.py

@@ -19,6 +19,7 @@ def _parser() -> argparse.ArgumentParser:
     )
     parser.add_argument("operation", nargs="?")
     parser.add_argument("--repo-root", type=Path, default=Path.cwd())
+    parser.add_argument("--purpose", choices=("application", "authoring"), required=True)
     mode = parser.add_mutually_exclusive_group()
     mode.add_argument("--list", action="store_true", dest="list_operations")
     mode.add_argument("--example", action="store_true")
@@ -112,7 +113,8 @@ def main(argv: list[str] | None = None) -> int:
     root = arguments.repo_root.resolve()
     try:
         contract = _object(root / GENERATED_CONTRACT)
-        operations = _operations(contract)
+        from tools.standards_engine.standards_engine.context_projection import qualified_operations
+        operations = _operations({"operations": qualified_operations(contract, arguments.purpose)})
         if arguments.list_operations:
             print("\n".join(sorted(operations)))
             return 0
@@ -137,18 +139,16 @@ def main(argv: list[str] | None = None) -> int:
                 "Engine runtime dependencies are unavailable; read "
                 ".agents/skills/standards-engine/references/environment.md"
             ) from error
-        with AgentToolFacade.open_repository(root) as facade:
+        with AgentToolFacade.open_repository(root, purpose=arguments.purpose) as facade:
             result = getattr(facade, str(operation["id"]))(request)
         print(json.dumps(result, indent=2, sort_keys=True))
         return 0
-    except (
-        AttributeError,
-        json.JSONDecodeError,
-        OSError,
-        TypeError,
-        ValueError,
-    ) as error:
-        print(f"standards-engine invocation error: {error}", file=sys.stderr)
+    except Exception as error:
+        # The CLI is an output boundary. Application callers receive a bounded
+        # outcome even when loading malformed private authority fails.
+        message = ("Application invocation is unavailable; use the published interface contract."
+                   if arguments.purpose == "application" else f"standards-engine invocation error: {error}")
+        print(message, file=sys.stderr)
         return 2