gh-inari 0.17.1 → 0.19.0

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "inari",
-  "version": "0.17.1",
+  "version": "0.19.0",
   "description": "Governed GitHub Issue/PR/template workflows via the inari CLI. Prefer inari over raw gh for operations it owns; use inari skill for operational playbooks.",
   "skills": "skills/inari"
 }

package/README.md

@@ -2,26 +2,28 @@
   <img src="./docs/assets/readme/inari-hero.webp" alt="Inari — GitHub Governance CLI. Standardize your workflow. Keep your project healthy." width="100%">
 </p>
 
-<p align="center">
-  <a href="https://github.com/yohn-jp/gh-inari/actions/workflows/ci.yml"><img alt="CI" src="https://github.com/yohn-jp/gh-inari/actions/workflows/ci.yml/badge.svg"></a>
-  <a href="https://www.npmjs.com/package/gh-inari"><img alt="npm" src="https://img.shields.io/npm/v/gh-inari"></a>
-  <a href="https://www.npmjs.com/package/gh-inari"><img alt="Node" src="https://img.shields.io/node/v/gh-inari"></a>
-  <a href="./LICENSE"><img alt="License" src="https://img.shields.io/npm/l/gh-inari"></a>
-</p>
-
 # Inari
 
 **Deterministic GitHub Governance**
 
-Inari (`inari`, published as `gh-inari`) turns repository-governed GitHub workflows into typed, deterministic contracts. It compiles repository-native Issue Forms and pull request templates, validates semantic input, renders canonical artifacts, and mediates governed work from **Issue → Change → PR → Merge**.
+Inari (`inari`, published as `gh-inari`) turns repository-governed GitHub work
+into typed, deterministic contracts. It resolves repository policy, validates
+semantic intent, renders canonical artifacts, admits bounded operations, and
+verifies their actual outcomes.
+
+The short lifecycle is **Issue → Change → PR → Merge**. A Source outcome,
+Implementation task, Session, leaf PR, and integration PR remain distinct
+identities within that workflow.
 
-Inari is intentionally not a general `gh` wrapper. Governed operations run through a closed, versioned command surface; unsupported or ambiguous behavior fails closed.
+Inari is not a general `gh` wrapper, arbitrary remote shell, credential
+sharing service, or agent scheduler. Unsupported or ambiguous authority fails
+closed rather than falling back to a broader credential.
 
 ## Quick start
 
 Requires Node.js 24 or newer.
 
-```bash
+```sh
 npm install --global gh-inari
 
 inari --version --json
@@ -29,186 +31,175 @@ inari template list
 inari issue schema feature --json
 ```
 
-For an ephemeral or PATH-independent invocation:
+An ephemeral invocation is also available:
 
-```bash
+```sh
 npx --yes gh-inari --version --json
 ```
 
-Inari uses the current GitHub authentication and repository context. Use `--repository owner/name` when the target is not the current checkout.
-
-To connect a repository Runtime, install the Inari GitHub App, then run the
-repository setup Golden Path:
-
-```bash
-inari setup
-# If setup reports trust-pending, open the printed Runtime Authority record
-# in a governed trust PR and merge it on the protected default branch.
-inari setup
-inari runtime connect
-```
-
-Setup stores only a repository-scoped, secret-free Runtime profile. It never
-commits, pushes, approves, or merges Runtime Authority trust; `ready` is
-reported only after canonical protected-ref readiness succeeds.
-
-The local setup state is shared by the CLI and a loopback browser console:
-
-```bash
-inari setup status          # canonical state and the one next action
-inari setup next            # perform exactly that action through its owner
-inari setup console         # owned loopback setup host; works before any key or trust
-```
-
-## The governed path
-
-```text
-Issue  →  Change  →  PR  →  Merge
- intent    governed   review   explicit
-           execution            outcome
-```
-
-A repository defines the contracts. Inari resolves those authorities, validates structured intent, produces canonical GitHub artifacts, and keeps lifecycle transitions bounded by explicit semantics rather than free-form CLI mutation.
-
-The Change surface exposes bounded lifecycle operations:
-
-```bash
-inari change issue <number> --json
-inari change show <number> --json
-inari change ready <number> --json
-inari change abort <number> --json
-```
+`inari` is the canonical executable; `gh-inari` is its npm binary alias.
+Use installed Help for the exact versioned command contract and explicit
+repository selection. Common shell behavior is being converged to CLI Canon;
+that migration does not change repository authorization.
 
-The normative end-to-end model lives in [Inari Golden Path Architecture](./docs/GOLDEN_PATH_ARCHITECTURE.md).
+## Architecture status
 
-### Integration routing
-
-Epic work may use three governed integration levels:
-
-```text
-Epic (epic/<number>-<slug>)
-  <- source Issue (issue/<number>-<slug>)
-       <- Implementation (feat|fix|refactor|test|docs|chore/<number>-<slug>)
-```
+The [Product Architecture Canon](./docs/ARCHITECTURE.md) records the approved
+2026-09-27 target. The [convergence ledger](./docs/ARCHITECTURE_CONVERGENCE.md)
+distinguishes current implementation, accepted changes, remaining integration,
+and required certification.
 
-Implementation PRs target the source-Issue branch, source-Issue integration PRs
-target the parent Epic branch, and Epic integration PRs target the governed
-default branch. The canonical routing projection validates relationships and
-uses branch names only as identity/consistency evidence. Sibling Implementations
-may proceed concurrently; merge order is not a dependency DAG. Standalone
-Issues and explicitly legacy in-flight Epic routes remain compatible.
+Documentation of a target is not a claim that every advertised interface or
+live deployment already implements it. In particular, the new Hosted
+assertion/Relay profile and retirement of independent Direct App execution
+require their governed implementation and public-path proof.
 
 ## Design principles
 
-| Principle              | Contract                                                                                                                                   |
-| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
-| **Canonical**          | One governed semantic input produces one canonical projection. Native GitHub artifacts remain interoperable, while ambiguity fails closed. |
-| **Deterministic**      | Resolution, validation, rendering, reconciliation, and lifecycle decisions are explicit and reproducible.                                  |
-| **Machine-verifiable** | Schemas, structured diagnostics, bounded JSON projections, and lifecycle evidence are designed for both humans and agents.                 |
+**Canonical:** each semantic fact has one owner; native GitHub artifacts and
+client interfaces are projections, not competing policy.
 
-## Core workflows
+**Deterministic:** the same admitted contract/input/evidence yields the same
+projection and plan. Unavailable evidence is not treated as absence.
 
-| Surface       | Purpose                                                                        | Start here                                   |
-| ------------- | ------------------------------------------------------------------------------ | -------------------------------------------- |
-| Templates     | Discover and synchronize repository governance                                 | `inari template list`, `inari template sync` |
-| Issues        | Schema, validate, render, create, read, observe, and reconcile governed Issues | `inari issue --help`                         |
-| Pull requests | Apply the same semantic pipeline to governed PRs                               | `inari pr --help`                            |
-| Change        | Enter and inspect the governed execution lifecycle                             | `inari change --help`                        |
-| Diagnostics   | Verify the installed runtime and required capabilities                         | `inari --diagnose --json`                    |
+**Machine-verifiable:** typed schemas, bounded diagnostics, current identity,
+and execution evidence support both humans and agents without exposing
+provider credentials.
 
-Typical structured preparation remains explicit:
+## Templates and semantic artifacts
 
-```bash
+Repositories define authoring contracts under `.github/inari/` or use the
+supported native-template compatibility path. Semantic source owns meaning;
+GitHub Issue Forms and PR Markdown are generated projections.
+
+```sh
 inari issue schema feature --json
 inari issue validate --template feature --from issue.json
 inari issue render --template feature --from issue.json
 inari issue create --template feature --from issue.json
 ```
 
-Use `--from -` to read JSON from stdin. Use `inari <domain> --help` for the exact versioned command contract rather than relying on a duplicated command catalog in this README.
+`--from -` selects stdin where supported. Pure schema/validation/rendering is
+not implicit provider mutation. Creation follows semantic validation,
+canonical rendering, freshness, and the admitted provider boundary.
 
-## Repository governance
+See [Semantic Templates](./docs/SEMANTIC_TEMPLATES.md) for exact discovery
+paths, native synchronization, import, and current compatibility. The
+schema-native target makes JSON Schema the generic data-shape authority while
+Inari retains value authority, relations, derivation, and provenance.
 
-Repository-native governance remains the interoperability boundary. Issue Forms under `.github/ISSUE_TEMPLATE/**` and supported pull request templates are compiled into typed contracts. Repositories using Inari's semantic template authority can define contracts under `.github/inari/` and regenerate their GitHub-native projections with:
+Existing artifact observation and reconciliation preserve human intent and
+free text. Automatic convergence may only perform proven semantics-preserving
+repair; missing intent or ambiguous template selection remains explicit.
 
-```bash
-inari template sync
-```
+## Source and Implementation
 
-See [Semantic template authority](./docs/SEMANTIC_TEMPLATES.md) for the authority and projection rules.
+A Source Issue defines the desired outcome and acceptance. An Implementation
+is the separate bounded task contract with scope, constraints, base/branch,
+dependencies, tests, and postconditions.
 
-Existing artifacts use the same compiler-owned semantic pipeline for validation and remediation. `get`, `view`, and `observe` deliberately expose different bounded projections; `check`, `edit`, `normalize`, and `sync` preserve explicit semantic intent and fail closed when preservation cannot be proven.
+Session task and leaf publication bind the Implementation. Source Change
+operations select a canonical Source in both the signed and current
+Implementation Source sets. Multiple Sources do not imply a primary Source
+or multiple implicit PR bases.
 
-## Implementation contracts
+WRITE never implies CREATE or DELETE. DENY and protected paths remain
+additional restrictions. Completion of one task/PR is not completion of its
+Source or Epic.
 
-One bounded execution session can be represented as a versioned `Implementation` contract. It records the objective, architecture decision, explicit `READONLY` / `WRITE` / `CREATE` / `DELETE` / `DENY` scopes, verification requirements, and base binding.
+See [Implementation Contract](./docs/IMPLEMENTATION_CONTRACT.md) and
+[Golden Path Composition](./docs/GOLDEN_PATH_ARCHITECTURE.md).
 
-`WRITE` is fail-closed and never implies `CREATE` or `DELETE`.
+## Runtime and operator experience
 
-The normative contract is documented in [Implementation Contract](./docs/IMPLEMENTATION_CONTRACT.md).
+Admission authenticates and authorizes. Executor owns Inari Access App custody,
+repository/installation binding, provider reads, and admitted effects.
+Authority owns delegation-signing keys. Setup and Console consume public owner
+ports and retain secret-free repository references.
 
-## Agents, Codex Plugin, and MCP
+The current local Setup entrypoints include:
 
-The published `gh-inari` package also contains the Codex Plugin manifest and bundled Inari Skill. There is no second package artifact. Codex plugin activation remains explicit; a normal npm install does not silently activate the plugin for an agent.
+```sh
+inari setup status
+inari setup next
+inari setup console
+```
 
-The bundled Skill stays deliberately thin: it routes governed workflows to `inari skill`, scenario-specific guidance, and the CLI's versioned help rather than duplicating operational policy.
+These expose canonical state and next action. Configuration, health, provider
+binding, repository trust, and Session readiness are not one ready flag.
+A trust PR must receive independent human approval/merge and protected-ref
+reread before trust is established.
 
-Inari also exposes MCP-facing capabilities backed by the same Core contracts and bounded projections used by the CLI. MCP is not a raw GitHub API pass-through.
+The target unified machine Console serves multiple isolated repository
+contexts. Connect, Disconnect, and rotation are recoverable owner operations,
+not implicit directory deletion or silent key regeneration.
 
-## Architecture
+Detailed key/bootstrap/recovery procedures are in
+[Delegator Operations](./docs/DELEGATOR_OPERATIONS.md). Explicit non-loopback
+transport is described in [Remote Runtime Transport](./docs/LOCAL_RUNTIME_NON_LOOPBACK.md).
 
-The README is an entry point, not a second architecture authority. Use these documents for normative detail:
+## Remote access target
 
-| Authority                                                      | Scope                                                                 |
-| -------------------------------------------------------------- | --------------------------------------------------------------------- |
-| [Golden Path Architecture](./docs/GOLDEN_PATH_ARCHITECTURE.md) | End-to-end governed lifecycle and composition                         |
-| [Architecture Vocabulary](./docs/ARCHITECTURE.md)              | Canonical provider, credential, principal, and observation vocabulary |
-| [Semantic Templates](./docs/SEMANTIC_TEMPLATES.md)             | Semantic template authority and GitHub-native projections             |
-| [Implementation Contract](./docs/IMPLEMENTATION_CONTRACT.md)   | Bounded implementation-session contract and scope model               |
+Hosted authenticates through Inari Access user OAuth, verifies caller and
+repository eligibility, and relays a short-lived signed request-bound
+assertion. It does not persist or forward the user's GitHub token.
 
-## Safety model
+A stable public Relay locator is derived from a separate user-owned transport
+key and bound to an authenticated live connection. The locator grants no
+repository permission. Private repositories do not require public discovery.
 
-Inari keeps mutation behind validated semantic boundaries:
+All repository semantics and subject/operation admission terminate on the
+user-owned Runtime. Normal provider effects use Executor-owned installation
+credentials. Hosted has no repository work database or alternate executor.
 
-```text
-resolve authority
-→ compile contract
-→ validate semantic input
-→ render canonical artifact
-→ verify round-trip
-→ perform the governed provider operation
-```
+See [Hosted Relay](./docs/HOSTED_RELAY_DEPLOYMENT.md) and
+[Repository Access Assertion](./docs/REPOSITORY_ACCESS_ASSERTION.md) for the
+approved boundaries and remaining implementation/certification gates.
 
-Schema, validation, rendering, observation, and dry-run paths do not become implicit mutation paths. Unsupported, ambiguous, unparseable, or semantically invalid state fails closed before provider mutation.
+## Agents, MCP, and packaged Skill
 
-Inari does not maintain a second credential store. Provider credentials and authority remain explicit parts of the architecture; see [Architecture Vocabulary](./docs/ARCHITECTURE.md).
+The published package contains the Codex Plugin manifest and bundled Inari
+Skill; activation is explicit. An npm installation does not silently activate
+an agent plugin.
 
-## Installation and diagnostics
+The Skill is a thin router to canonical playbooks, Help, and repository
+execution governance. It does not override a repository's active restrictions
+or maintain a second command/permission catalog.
 
-Update or remove a global installation with npm:
+MCP exposes the same typed operation contracts. Hosted MCP relays rather than
+running a second semantic backend. Protocol access grants no shell, raw GitHub
+proxy, review, merge, or operator-enrollment authority.
 
-```bash
-npm install --global gh-inari@latest
-npm uninstall --global gh-inari
-```
+## Security boundaries
 
-Run the bounded standalone diagnostic without changing repository files:
+Caller identity is not provider execution identity. App credentials remain
+inside Executor, delegation keys at Authority, and Relay transport keys at
+the user-owned client. Admission receives validated evidence, not provider
+credentials.
 
-```bash
-inari --diagnose --json
-npx --yes gh-inari --diagnose --json
-```
+A successful provider response is not enough: execution rereads authoritative
+state and verifies the planned postcondition. Timeouts after possible effects
+retain uncertainty and require safe reconciliation, not blind replay.
 
-`inari --version --json` is the machine-readable self-check. The canonical executable is `inari`; `gh-inari` is an npm bin alias resolving to the same entry point.
+See [Security Policy](./SECURITY.md),
+[Caller Authentication](./docs/AGENT_CAPABILITY_AUTHORIZATION.md), and
+[Inari Access](./docs/INARI_ISSUER_APP.md).
 
-## Development
+## Development and verification
 
-```bash
+```sh
 pnpm install --frozen-lockfile
 pnpm run verify
 ```
 
-`pnpm run verify` is the repository's authoritative local verification entry point.
+`pnpm run verify` remains the authoritative local entrypoint. Source, built,
+installed-package, process, browser, and live-provider evidence are different
+proof classes. The target removes duplicate execution at the same boundary
+and separates routine verification from release-preparation certification.
+
+Read [Verification Architecture](./docs/VERIFICATION_ARCHITECTURE.md) and
+[Contributing](./CONTRIBUTING.md). A pending, environment-blocked, or unexecuted
+check is never reported as passed.
 
 ## License
 

package/dist/admission/authorization.d.ts

@@ -28,7 +28,15 @@ export interface AdmissionAuthorizationOptions {
      */
     readonly readBranchPolicy?: (request: LocalExecutorBranchPolicyRequest) => Promise<unknown>;
 }
-/** Current, owner-acquired branch-policy input for one governed Implementation. */
+/**
+ * Current, owner-acquired branch-policy input for one governed Implementation.
+ *
+ * #1213: when the owner projects the Implementation's canonical Source set,
+ * Admission attaches the certificate-safe projection of the current authorized
+ * Implementation carrying that set. The Session launcher signs it as the upper
+ * bound of Source-rooted change.* capabilities; the Session task stays the
+ * Implementation. The projected set must equal the owner's parsed set.
+ */
 export declare function currentBranchPolicyInput(repository: SessionCertificateRepository, implementation: number, options: AdmissionAuthorizationOptions, stage: RuntimeFailureStage): Promise<LocalBranchPolicyInput>;
 export interface AdmittedSession {
     readonly id: string;