renma 0.17.0 → 0.18.1

package/examples/context-lens/lenses/testing/test-design-boundary-values.md

@@ -11,8 +11,15 @@ tags:
 purpose: test_design
 applies_to:
   - context.testing.boundary-value-analysis
-focus: inclusive limits, empty and zero values, overflow behavior, retry limits
-expected_outputs: test cases, edge-case checklist, coverage notes
+focus:
+  - inclusive limits
+  - empty and zero values
+  - overflow behavior
+  - retry limits
+expected_outputs:
+  - test cases
+  - edge-case checklist
+  - coverage notes
 allowed_data:
   - repo-local-files
 network_allowed: false
@@ -22,8 +29,23 @@ requires_human_approval: false
 ---
 # Test Design Lens for Boundary Values
 
-Use this lens when turning boundary value analysis context into concrete test coverage.
+Interpret the applied boundary-value Context for test design that provides
+reviewable evidence of behavior at and around material limits.
 
-Emphasize lower and upper bounds, inclusive and exclusive behavior, empty input, zero values, overflow, maximum retries, and expected failure modes.
+## Interpretation Criteria
 
-The lens should help produce test cases and coverage notes. It should not select runtime context, assemble a prompt, or duplicate the base boundary value analysis context.
+- Map each declared limit to cases below, at, and above the boundary when those
+  states are valid for the system.
+- Distinguish inclusive from exclusive behavior and cover empty input, zero
+  values, overflow, maximum retries, and expected failure modes when applicable.
+- Trace each proposed case to a stated requirement and identify any expected
+  result that the specification leaves unresolved.
+- Prefer deterministic cases whose setup, assertion, and failure evidence can
+  distinguish product behavior from a test defect.
+
+## Evidence And Output
+
+Produce test cases, an edge-case checklist, and coverage notes with requirement
+citations. Keep unresolved expected results explicit. Do not select runtime
+Context, assemble a prompt, define the Skill workflow, or duplicate the base
+Context.

package/examples/context-lens/skills/testing/spec-review/SKILL.md

@@ -19,7 +19,15 @@ metadata:
 
 Use this skill to review a specification before implementation or test design.
 
-The skill stays thin. It declares the reusable base context and the purpose-oriented lens, while the detailed knowledge remains in context assets and lens assets.
+This Skill owns the focused review workflow. The declared Context Asset owns
+reusable boundary-value knowledge, and the declared Lenses own purpose-specific
+interpretation of that knowledge.
+
+## Selection Boundaries
+
+Use this workflow when a specification needs evidence-backed analysis of
+implementation or test-design boundaries. Do not use it to implement the
+change, approve product decisions, or perform unrelated editorial review.
 
 ## Required Inputs
 
@@ -28,9 +36,28 @@ The skill stays thin. It declares the reusable base context and the purpose-orie
 
 ## Instructions
 
-1. Read the declared context assets.
-2. Apply the declared context lens to focus the review.
-3. Produce unresolved questions, risk notes, and clarification suggestions.
+1. Confirm that the supplied specification and its sources are available. If a
+   required source is missing, record the gap rather than inventing behavior.
+2. Read the declared boundary-value Context Asset and the required spec-review
+   Lens. Apply the optional test-design Lens only when test coverage is also in
+   scope for the requested review.
+3. Extract stated behavior, limits, assumptions, and sources from the supplied
+   specification. Keep facts separate from inferences and unresolved questions.
+4. Apply the required Lens's interpretation criteria to the reusable Context.
+   Cite the reusable guidance where relevant instead of reproducing it in this
+   Skill or output.
+5. Prioritize findings by implementation or release risk. Cite the relevant
+   specification section or repository evidence for every finding.
+6. Produce the expected output below and leave decisions with the accountable
+   human owner.
+
+## Expected Output
+
+- A short scope and evidence summary.
+- Prioritized unresolved questions and risk notes.
+- Clarification suggestions tied to cited source gaps.
+- The Context and Lens IDs applied, including why the optional Lens was or was
+  not used.
 
 ## When Not To Use
 
@@ -41,6 +68,8 @@ approval, or an editorial workflow for copy-only review.
 
 - The output distinguishes known facts from open questions.
 - The output cites the source-of-truth gaps it found.
+- Each finding has an impact or risk and an evidence-backed rationale.
+- Use of the optional Lens matches the requested review scope.
 - The skill does not copy reusable testing guidance into this file.
 
 ## Completion Criteria

package/examples/context-repo/README.md

@@ -85,7 +85,7 @@ Run these commands from the renma repository root after building the CLI:
 
 ```bash
 npm run build
-node dist/index.js scan examples/context-repo
+node dist/index.js scan examples/context-repo --fail-on high
 node dist/index.js catalog examples/context-repo --format markdown
 node dist/index.js ownership examples/context-repo --format markdown
 node dist/index.js graph examples/context-repo --view layered --format mermaid
@@ -99,7 +99,7 @@ node dist/index.js inspect examples/context-repo/skills/testing/spec-review/SKIL
 With an installed CLI, replace `node dist/index.js` with `renma`:
 
 ```bash
-renma scan examples/context-repo
+renma scan examples/context-repo --fail-on high
 renma catalog examples/context-repo --format markdown
 renma ownership examples/context-repo --format markdown
 renma graph examples/context-repo --view layered --format mermaid
@@ -118,11 +118,10 @@ evidence into authoritative JSON or a Markdown review projection. `inspect`
 shows the structure of the workflow entrypoint.
 
 The example is structurally ready: its Skill and Lens validate, every declared
-relationship resolves, and every cataloged asset has an owner. `scan` also
-keeps advisory missing-security-policy findings visible for the fixture's
-Skill and Context Assets. The example does not invent security policy merely to
-produce an empty finding list; fixture owners would need to review and declare
-that policy.
+relationship resolves, and every cataloged asset has an owner. Its Skill and
+Context Assets declare a local-only security policy for repository files,
+explicitly disclosed user inputs, and the Context bundled with the Skill, so
+`scan` completes without diagnostics or security findings.
 
 ## Intentionally Not Demonstrated
 

package/examples/context-repo/contexts/domain/payment/idempotency.md

@@ -11,6 +11,13 @@ when_to_use:
   - Reviewing payment write retry behavior or duplicate request handling
 when_not_to_use:
   - Reviewing non-payment retries or read-only request behavior
+allowed_data:
+  - repo-local-files
+  - disclosed-user-provided-data
+network_allowed: false
+external_upload_allowed: false
+secrets_allowed: false
+requires_human_approval: true
 ---
 
 # Payment Idempotency

package/examples/context-repo/contexts/testing/boundary-value-analysis.md

@@ -10,6 +10,13 @@ when_to_use:
   - Designing test cases around numeric, date, count, length, or pagination limits
 when_not_to_use:
   - Testing invalid inputs that are not tied to explicit boundary values
+allowed_data:
+  - repo-local-files
+  - disclosed-user-provided-data
+network_allowed: false
+external_upload_allowed: false
+secrets_allowed: false
+requires_human_approval: true
 ---
 
 # Boundary Value Analysis

package/examples/context-repo/contexts/testing/negative-testing.md

@@ -10,6 +10,13 @@ when_to_use:
   - Designing validation, unsupported-state, or error-handling test cases
 when_not_to_use:
   - Designing accepted boundary-value cases for valid limits
+allowed_data:
+  - repo-local-files
+  - disclosed-user-provided-data
+network_allowed: false
+external_upload_allowed: false
+secrets_allowed: false
+requires_human_approval: true
 ---
 
 # Negative Testing

package/examples/context-repo/skills/testing/spec-review/SKILL.md

@@ -11,6 +11,11 @@ metadata:
   renma.requires-context: '["contexts/testing/negative-testing.md"]'
   renma.optional-context: '["context.domain.payment.idempotency"]'
   renma.requires-lens: '["lens.testing.spec-review.boundary-values"]'
+  renma.allowed-data: '["repo-local-files","skill-bundled-context","disclosed-user-provided-data"]'
+  renma.network-allowed: "false"
+  renma.external-upload-allowed: "false"
+  renma.secrets-allowed: "false"
+  renma.requires-human-approval: "true"
 ---
 
 # Spec Review

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "renma",
-  "version": "0.17.0",
+  "version": "0.18.1",
   "description": "Manage human-curated context assets for LLMs and agents in Git.",
   "license": "MIT",
   "repository": {
@@ -57,6 +57,8 @@
   "devDependencies": {
     "@eslint/js": "^10.0.1",
     "@types/node": "^22.15.30",
+    "ajv": "^8.20.0",
+    "ajv-formats": "^3.0.1",
     "eslint": "^10.5.0",
     "eslint-config-prettier": "10.1.8",
     "prettier": "^3.5.3",

package/plan-discovery.md

@@ -1,24 +1,26 @@
 # Renma Skill Discovery Plan
 
-Status: proposed
+Status: deferred exploratory design
 
-Target: 0.18.0
+Target: unassigned (post-0.18.0)
 
 Scope: optional, backward-compatible skill discovery for large single repositories
 
-Only **Current Baseline** describes implemented behavior. Route metadata,
-`skill-index`, discovery diagnostics, and the integrations proposed elsewhere in
-this document are not implemented in 0.17.0. This plan is intentionally outside
-the 0.17.0 usability and documentation-consolidation release.
+Only **Current Baseline** describes implemented behavior. `routes_to`,
+`skill-index`, discovery aliases, explicit routing entrypoints, generated
+indexes, and related diagnostics are deferred proposals. They are not Renma
+0.18.0 behavior and have no assigned release. Runtime Skill selection remains
+outside Renma.
 
 ## Summary
 
 Renma should add a static skill discovery projection for repositories that have grown beyond the point where an agent can reliably inspect every `SKILL.md` before choosing where to start.
 
-The implementation should preserve Renma's current model and boundaries:
+Any future implementation must be reconsidered against Renma's focused-workflow
+model and boundaries:
 
 ```text
-Skill = agent-facing entrypoint / routing contract / usage guide
+Skill = focused, bounded workflow entrypoint and usage guide
 Context Lens = purpose-oriented interpretation layer over context assets
 Context Asset = independently owned source-of-truth knowledge
 ```
@@ -43,23 +45,30 @@ LLM proposes. Renma verifies. Human approves.
 
 ## Current Baseline
 
-The current 0.16.0 product model provides most of the infrastructure needed for
-this work, and 0.17.0 improves the usability of that baseline without
-implementing discovery:
+The implemented 0.18.0 product provides infrastructure that a future design
+could reuse without implementing Skill-to-Skill routing:
 
-- Repository discovery for skills, context assets, context lenses, profiles, references, examples, agents, config, and supporting files.
+- Repository file discovery for Skills, Context Assets, Context Lenses,
+  profiles, references, examples, scripts, assets, agents, and config.
+- First-class Skill-local support discovery, static reachability and ownership
+  relationships, and no-follow symlink handling.
 - A normalized catalog model with deterministic IDs, paths, hashes, owners, lifecycle metadata, tags, and declared dependencies.
 - A shared `RepositoryEvidence` collection path used by catalog, graph, and Repository Context BOM work.
 - Static graph relationships for required and optional context, required and optional lenses, lens application, conflicts, supersession references, and coverage evidence.
 - Markdown, JSON, and Mermaid reports for human review, CI, and downstream tooling.
-- Readiness, semantic diff, ownership, Trust Graph, diagnostics v2, review bundles, scaffold, and metadata suggestions.
+- Readiness, semantic diff, ownership, Trust Graph v2, Repository Context BOM
+  v2, diagnostics v2, review bundles, scaffold, and metadata suggestions.
+- Effective security-policy provenance across local metadata, profiles,
+  repository configuration, and owning-Skill inheritance.
 - A compact metadata parser that supports scalar values and selected block-list fields while intentionally discouraging large nested frontmatter.
 
-Skill discovery should extend this baseline. It should not create a parallel scanner, a second catalog, a new runtime service, or a separate source of truth.
+Deferred Skill-to-Skill discovery is distinct from this implemented repository
+and support-resource discovery. Any future work must not create a parallel
+scanner, second catalog, runtime service, or separate source of truth.
 
 ## Decision Status
 
-Accepted constraints for 0.18.0 design are:
+Constraints for any future design are:
 
 - Renma remains a deterministic repository-governance layer, not a runtime
   selector.

package/plan.md

@@ -2,149 +2,89 @@
 
 ## Current Product Definition
 
-Renma is a Git-native context repository and deterministic governance CLI for
-agent-consumable Skills, Context Lenses, Context Assets, references, policies,
-ownership, lifecycle, dependencies, and evidence.
+Renma 0.18.0 is the current shipped baseline: a Git-native context repository
+and deterministic governance CLI for agent-consumable Skills, Context Lenses,
+Context Assets, local support resources, policies, ownership, lifecycle,
+dependencies, and review evidence.
 
 ```text
-Skill = agent-facing entrypoint, routing contract, and workflow guide
+Skill = focused, bounded workflow entrypoint
 Context Lens = purpose-oriented interpretation over Context Assets
 Context Asset = independently owned source-of-truth knowledge
 ```
 
-Use platform-native Skill authoring guidance for general Skill design, then use
-Renma for repository-specific governance and validation. Renma keeps repository
-assets discoverable, compatible, owned, linked, validated, reviewable, and
-measurable in Git and CI.
-
-Renma's deterministic core follows:
+Use platform-native guidance for general Skill authoring, then use Renma for
+repository-specific governance. Renma follows the deterministic boundary:
 
 ```text
 LLM proposes. Renma verifies. Human approves.
 ```
 
-No-LLM workflows remain first-class.
-
-## Stable Product Boundaries
+## Implemented 0.18.0 Baseline
 
-Renma owns:
+The shipped baseline includes:
 
-- repository discovery and parsing;
-- a normalized asset and relationship model;
-- Agent Skills compatibility checks;
-- catalog, ownership, graph, Trust Graph, Readiness, and BOM projections;
-- deterministic workflow, metadata, lifecycle, relationship, maintenance, and
-  security diagnostics;
-- semantic diff and CI review evidence; and
-- deterministic scaffold and non-editing suggestion output.
+- focused workflow Skills with explicit usage boundaries rather than thin
+  routing-only entrypoints;
+- progressive disclosure through static, reviewable references;
+- first-class Skill-local `references/`, `profiles/`, `examples/`, `scripts/`,
+  and `assets/` resources under `skills/**` and `.agents/skills/**`;
+- deterministic ownership, reachability, helper-command, and static support
+  relationships, including ambiguity that fails closed;
+- repository-bounded discovery that never follows leaf or directory symlinks,
+  with actionable evidence for referenced unusable paths;
+- canonical Agent Skills compatibility, migration guidance, scaffold, inspect,
+  and non-editing suggestion workflows;
+- catalog, graph, ownership, Readiness, semantic diff, CI, diagnostics v2, and
+  review-bundle projections;
+- security diagnostics, reusable profiles, effective-policy inventory, and
+  deterministic compositional policy provenance; and
+- Repository Context BOM v2 and Trust Graph v2 as the first supported
+  long-term contracts and the only emitted BOM/Trust Graph schemas.
+
+Repository Context BOM v2 is a declared repository manifest, not a record of
+what an LLM consumed. Trust Graph v2 is deterministic review evidence, not a
+subjective score or runtime enforcement system.
+
+Historical release detail belongs in [CHANGELOG.md](CHANGELOG.md). Contract
+details live in [architecture.md](architecture.md), [design.md](design.md), and
+the focused documents under [docs/](docs/README.md).
 
-Renma does not own:
+## Stable Product Boundaries
 
-- general Skill authoring logic supplied by platforms;
-- live Skill or Context selection;
-- prompt assembly or Context injection;
-- Skill, agent, or tool execution;
-- runtime telemetry collection;
-- hosted dashboards or provider gateways;
-- automatic semantic rewriting; or
-- automatic policy weakening or suppression creation.
+Renma owns repository discovery and parsing, normalized static evidence,
+validation, deterministic projections, and review-oriented authoring support.
+It does not own live Skill or Context selection, prompt assembly, execution,
+runtime telemetry, hosted gateways, automatic semantic rewriting, or automatic
+policy weakening.
 
-Repository Context BOM v1 remains a declared repository manifest, not a record
-of what an LLM consumed. Trust Graph remains deterministic review evidence, not
-a subjective trust score or runtime enforcement system.
+## Deferred Skill-to-Skill Discovery Design
 
-## Completed Baseline Through 0.16.0
+Graph-based Skill-to-Skill route discovery is not a 0.18.0 feature and has no
+assigned release. The exploratory design in
+[plan-discovery.md](plan-discovery.md) discusses possible `routes_to` metadata,
+discovery aliases, generated routing indexes, and a `skill-index` projection.
+None is an implemented contract.
 
-The shipped baseline includes:
-
-- deterministic repository scanning, catalog, ownership, graph, focused graph,
-  Readiness, semantic diff, and CI reports;
-- first-class Context Assets and Context Lenses with graph-backed validation;
-- repeated-context and workflow diagnostics;
-- security diagnostics, reusable policy profiles, posture summaries, and
-  effective policy inventory;
-- Trust Graph evidence and Repository Context BOM v1;
-- `inspect`, `scaffold`, `suggest-metadata`, and
-  `suggest-semantic-split` authoring support;
-- LLM-actionable diagnostics v2 and review bundles; and
-- the canonical Agent Skills-compatible Skill format introduced in 0.16.0,
-  with flat string-valued `metadata.renma.*` governance and security fields and
-  a conservative one-way migration path.
-
-Historical release detail belongs in [CHANGELOG.md](CHANGELOG.md). Authoritative
-technical contracts remain in [architecture.md](architecture.md),
-[design.md](design.md), and the focused documents under [docs/](docs/README.md).
-
-## 0.17.0: Usability And Documentation Consolidation
-
-Renma 0.17.0 improves the usability and consistency of the authoring and
-governance workflows established in 0.16.0. It clarifies documentation, CLI
-guidance, and the handoff between platform-native Skill authoring and Renma's
-repository-specific validation.
-
-The release focuses on:
-
-- making the new-Skill authoring → scaffold → scan → refine loop discoverable;
-- making the existing-Skill review → suggest-metadata → scan → refine loop
-  discoverable;
-- keeping generic CLI guidance platform-neutral;
-- preserving conservative blocked migration and non-editing behavior;
-- consolidating README, user-manual, authoring, compatibility, architecture,
-  design, and roadmap responsibilities; and
-- retaining detailed BOM, security, migration, diagnostic, and repository-model
-  contracts in focused documents.
-
-This release does not add a major command, new schema, discovery model, runtime
-capability, packaging system, or telemetry import.
-
-## 0.18.0: Graph-Based Skill Discovery
-
-The next proposed capability is a static Skill discovery projection for large
-single repositories. The target is 0.18.0, not 0.17.0.
-
-The proposal may add exact Skill-to-Skill route evidence, a static
-`skill-index` report, conservative entrypoint inference, deterministic
-discovery diagnostics, and later Readiness/diff integrations. It must preserve
-the source `SKILL.md` files, the non-runtime boundary, deterministic outputs,
-and backward compatibility.
-
-The design is proposed rather than implemented. See
-[plan-discovery.md](plan-discovery.md) for prototype knowledge, open decisions,
-phases, and non-goals.
+Any future proposal must be reconsidered against the focused-workflow model
+introduced in 0.18.0. It must remain deterministic and static, avoid runtime
+selection, preserve source Skills, and receive an explicit version and contract
+decision before implementation.
 
 ## Later Candidates
 
-Later work may consider:
-
-- importing separately produced consumed-context evidence after a stable,
-  versioned contract exists;
-- additive BOM or Trust Graph projections for stable discovery evidence;
-- optional semantic review helpers that consume explicit deterministic bundles;
-- multi-repository or distribution workflows after the single-repository model
-  is stable; and
-- review visualizations derived from versioned report contracts.
-
-These candidates require explicit product decisions. They are not commitments
-and must not blur repository governance with runtime execution or telemetry
-ownership.
+Future product decisions may consider imported external consumed-context
+evidence, additive projections over stable evidence, optional semantic-review
+helpers, multi-repository workflows, or review visualizations. These are not
+commitments and have no assigned version.
 
 ## Explicitly Out Of Scope
 
-The current roadmap excludes:
-
 - accepting task text and automatically selecting or ranking a Skill;
 - fuzzy, embedding, or LLM-based runtime routing;
-- runtime Context selection, loading, injection, or prompt assembly;
-- Skill or agent execution and tool orchestration;
-- automatic Skill body rewriting;
-- platform-native authoring logic inside Renma;
-- arbitrary Skill roots without a separately reviewed compatibility decision;
-- package publication, Context materialization, or repository distribution;
+- runtime Context loading, injection, prompt assembly, or execution;
 - runtime telemetry collection or hidden consumed-context import;
-- BOM v2 without a demonstrated breaking-contract need;
-- automatic policy relaxation or suppression generation; and
-- new metadata semantics without an implemented deterministic consumer.
-
-The roadmap should stay current-facing. Completed behavior belongs in the
-baseline and changelog; detailed semantics belong in their canonical technical
-documents; proposed discovery remains isolated in the 0.18.0 plan.
+- automatic Skill-body rewriting or policy relaxation;
+- arbitrary Skill roots without a reviewed compatibility decision; and
+- advertising deferred `routes_to`, `skill-index`, aliases, or generated
+  routing indexes as current behavior.

package/scripts/verify-package.mjs

@@ -23,7 +23,14 @@ try {
   }
   const files = new Set(report.files.map((file) => file.path));
 
-  for (const required of ["package.json", "README.md", "dist/index.js"]) {
+  for (const required of [
+    "package.json",
+    "README.md",
+    "dist/index.js",
+    "docs/trust-graph.md",
+    "docs/schemas/repository-context-bom-v2.schema.json",
+    "docs/schemas/trust-graph-v2.schema.json",
+  ]) {
     requirePackagedPath(files, required);
   }