@c4a/context-cli 0.6.11 → 0.6.16

package/providers/context/resources/semantic/code-index/templates/web-application.md

@@ -0,0 +1,145 @@
+---
+id: semantic.code-index.template.web-application
+kind: procedure
+media-type: text/markdown
+---
+
+# Web and interactive application template
+
+Use only after evidence classifies a module as `web-application`. This covers
+browser applications, server-rendered sites, embedded WebViews, desktop Web
+shells, native mobile/desktop applications, cross-platform UI runtimes, and
+similar interactive modules. The `web-application` identifier is retained for
+the current contract but represents an interactive application boundary, not
+only browser code. It does
+not automatically cover every package containing UI components; a reusable
+component package is usually `sdk-library`.
+
+Recommended `outputProfile`: `application-map`.
+
+## Evidence pass
+
+Locate the concrete application bootstrap and trace outward just far enough to
+find:
+
+- application mounting, server rendering, shell, or host-container entry;
+- route/page/screen registries and navigation guards;
+- page-to-state, loader, query, client, bridge, or controller boundaries;
+- runtime configuration, environment selection, feature registration, and
+  authentication/session initialization;
+- build, local development, test, bundle, and release entrypoints;
+- generated clients, assets, styles, fixtures, and legacy routes that should
+  remain evidence rather than reader-facing pages.
+
+If the route registry is generated, locate both its generator or source of
+truth and the runtime consumer. Do not infer page identity from a directory
+tree when an explicit registry exists.
+
+## Questions the knowledge must answer
+
+A useful application index should let a reader determine:
+
+1. How does the application start, and which runtime or host does it expect?
+2. What are the stable pages/routes/screens and their entry components?
+3. How does a page obtain data or call an external capability?
+4. Which state, session, bridge, or configuration boundaries affect behavior?
+5. How is the module run, debugged, built, and released?
+6. Which implementation details are intentionally outside the knowledge scope?
+
+## Suggested knowledge units
+
+Select only units supported by the confirmed goal and evidence:
+
+- **Application map**: responsibility, runtime, bootstrap, major subsystems,
+  stable dependencies, and navigation to deeper pages.
+- **Route or page registry**: concrete route/page identity, entry component,
+  loader/guard, main data boundary, and source locator. Aggregate related
+  routes when a page-per-route layout would be repetitive.
+- **Data and protocol boundaries**: add application-specific page, state, and
+  session context to the canonical operation record in `protocol-boundary.md`;
+  do not create a second operation registry.
+- **State and host integration**: only stable stores, bridges, extension points,
+  or host contracts that affect multiple pages or public behavior.
+- **Runtime and delivery guide**: module-owned development commands,
+  configuration, build output, deployment/release entry, and evidenced recovery
+  paths.
+- **Cross-layer flow**: a source-backed page-to-client-to-provider chain when
+  both sides are registered sources.
+
+These are possible page families, not a required number of Markdown files.
+
+## Chapter blueprints
+
+An application-map page may use:
+
+```markdown
+# <Application> module map
+## Responsibility and supported runtime
+## Bootstrap sequence
+## Route/page organization
+## State, data, and protocol boundaries
+## Host integrations and extension points
+## Configuration and environment selection
+## Development, build, and release entrypoints
+## Known exclusions and source-of-truth links
+```
+
+A route/page registry may use a compact record rather than prose repetition:
+
+```markdown
+## <Route or page family>
+- Identity and registration:
+- Entry component or controller:
+- Loader, guard, or initialization:
+- Main client/state dependencies:
+- User-visible outcome:
+- Source evidence:
+```
+
+A cross-layer page may use:
+
+```markdown
+# <User interaction> execution path
+## Trigger and route entry
+## UI/state orchestration
+## Protocol request and authoritative contract
+## Provider boundary and response handling
+## Failure, fallback, and observability
+## Source-backed relationship chain
+```
+
+Do not fill a heading with generic text. Omit or mark a section as a material
+gap when the source cannot support it.
+
+## Granularity and relationships
+
+Prefer stable application concepts over one page per component, hook, state
+field, style, generated type, or internal helper. A page registry must contain
+real identities and source locators, not just folder names. A protocol page
+must name concrete operations or contract locations, not merely state that the
+application “uses HTTP”.
+
+Create structured relationships only when registration, call sites, imports
+with unambiguous ownership, or parser evidence support them. Keep inferred
+product intent out of the index.
+
+## Template composition examples
+
+- A server-rendered application with local API routes also reads
+  `api-service.md` and `protocol-boundary.md`.
+- An embedded application with a host bridge also reads `adapter.md` and the
+  applicable `plugin-extension.md` or `protocol-boundary.md` template.
+- A design-system package rendered in a demo application may need separate
+  index units: `sdk-library` for the supported package and `web-application`
+  for the demo host.
+
+## Revise or stop when
+
+- no executable bootstrap or route registry can be located;
+- the proposed output is only a directory summary;
+- protocol semantics depend on unavailable material;
+- generated routes or clients are being mistaken for authoritative behavior;
+- one-symbol-per-page selection expands components or API types without a
+  deliberate public-reference goal.
+
+Resolve these issues before the measured batch preview.

package/providers/context/resources/views/document-optimization-current.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.document-optimization-current
+kind: context-view
+mediaType: text/markdown
+description: Current document revision status and pending batch size.
+materializer: actions/materialize-context-view.yaml

package/providers/context/resources/views/extraction-preview.yaml

@@ -0,0 +1,6 @@
+schema: agent-graph.resource.v1
+id: context.extraction-preview
+kind: context-view
+mediaType: text/markdown
+description: Current batch code-extraction scale, output profile, ownership, structural probe coverage, and capability report.
+materializer: actions/materialize-context-view.yaml

package/providers/context/schemas/document-optimization-decisions.schema.json

@@ -0,0 +1,34 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "context.document-optimization-decisions.v1",
+  "title": "Context document optimization decisions",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema", "decisions"],
+  "properties": {
+    "schema": { "const": "context.document-optimization-decisions.v1" },
+    "decisions": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": ["fragment_id", "input_digest", "context_digest", "policy_digest", "action"],
+        "properties": {
+          "fragment_id": { "type": "string", "minLength": 1 },
+          "input_digest": { "type": "string", "minLength": 1 },
+          "context_digest": { "type": "string", "minLength": 1 },
+          "policy_digest": { "type": "string", "minLength": 1 },
+          "action": { "enum": ["keep", "replace"] },
+          "replacement": { "type": "string" },
+          "reason": { "type": "string" }
+        },
+        "allOf": [
+          {
+            "if": { "properties": { "action": { "const": "replace" } } },
+            "then": { "required": ["replacement"] }
+          }
+        ]
+      }
+    }
+  }
+}