igniter 0.5.0 → 0.5.2

data/docs/guide/application-capsules.md

@@ -0,0 +1,139 @@
+# Application Capsules
+
+Application capsules are the copyable unit for Igniter apps. A capsule keeps
+contracts, services, optional web surfaces, imports, exports, and review
+metadata local to one application boundary.
+
+Use capsules when an app should be understandable before it is loaded, mounted,
+copied, or connected to a larger host.
+
+## Shape
+
+Small capsules stay sparse: create only the folders the app owns.
+
+```ruby
+capsule = Igniter::Application.capsule(:operator, root: "apps/operator") do
+  layout :capsule
+  groups :contracts, :services
+
+  export :resolve_incident,
+         kind: :contract,
+         target: "Contracts::ResolveIncident"
+
+  import :incident_runtime,
+         kind: :service,
+         from: :host,
+         capabilities: [:incidents]
+end
+
+blueprint = capsule.to_blueprint
+```
+
+The explicit data form is equally valid:
+
+```ruby
+blueprint = Igniter::Application.blueprint(
+  name: :operator,
+  root: "apps/operator",
+  layout_profile: :capsule,
+  groups: %i[contracts services]
+)
+```
+
+Use the data form for generators and diffs. Use the DSL form for human-edited
+application code.
+
+## Web Is Optional
+
+A capsule can be web-capable without becoming a web framework object.
+`igniter-application` accepts plain surface metadata; `igniter-web` owns
+screens, routes, components, and rendering details.
+
+```ruby
+blueprint = Igniter::Application.blueprint(
+  name: :operator,
+  root: "apps/operator",
+  layout_profile: :capsule,
+  groups: %i[contracts services],
+  web_surfaces: [:operator_console]
+)
+```
+
+This keeps non-web and web-capable apps in the same application vocabulary.
+
+## Reports
+
+Capsule reports are read-only inspection output. They summarize:
+
+- identity and layout profile
+- active and known groups
+- planned sparse and complete paths
+- imports and exports
+- optional features, flows, and supplied surface metadata
+
+Reports do not load constants, create files, execute contracts, mount web
+surfaces, or boot an app.
+
+```ruby
+report = blueprint.capsule_report
+report.to_h
+```
+
+## Transfer
+
+Capsule transfer is review-first. The lifecycle is deliberately explicit:
+
+1. inspect the capsule with `capsule_report`
+2. review physical files with `transfer_inventory`
+3. check readiness with `transfer_readiness`
+4. build a `transfer_bundle_plan`
+5. write and verify a transfer bundle
+6. preview destination intake
+7. dry-run apply operations
+8. commit only reviewed file operations
+9. verify the applied transfer
+10. close with `transfer_receipt`
+11. optionally record the result in an installed-capsule registry
+
+Only the explicit committed apply step mutates the destination filesystem.
+Host wiring, load paths, provider registration, web route activation, contract
+execution, and cluster placement remain outside transfer.
+
+Installed-capsule registries are application state, not hub state. A hub can
+discover a candidate bundle, but `igniter-application` owns the receipt-backed
+record that says what was installed, whether it is complete, and which source
+and version produced it. The file-backed registry keeps current state separate
+from append-only history so future upgrade, rollback, and audit flows can build
+on the same receipt trail.
+
+Runnable end-to-end example:
+
+```bash
+ruby examples/application/capsule_transfer_end_to_end.rb
+```
+
+## Activation Boundary
+
+A complete transfer receipt means reviewed files landed and verified. It does
+not mean the receiving host activated the app.
+
+Host activation is a separate review lane:
+
+- `host_activation_readiness`
+- `host_activation_plan`
+- `verify_host_activation_plan`
+- optional ledger-backed acknowledgement receipts
+
+The current ledger path records reviewed confirmations. It is not live host
+mutation and does not boot providers, bind routes, execute contracts, or touch a
+cluster.
+
+## Examples
+
+- [`examples/application/capsule_composition.rb`](../../examples/application/capsule_composition.rb)
+- [`examples/application/capsule_assembly_plan.rb`](../../examples/application/capsule_assembly_plan.rb)
+- [`examples/application/capsule_transfer_end_to_end.rb`](../../examples/application/capsule_transfer_end_to_end.rb)
+- [`examples/application/capsule_host_activation_readiness.rb`](../../examples/application/capsule_host_activation_readiness.rb)
+
+For app/web conventions, continue with
+[Interactive App Structure](./interactive-app-structure.md).

data/docs/guide/application-showcase-portfolio.md

@@ -0,0 +1,181 @@
+# Application Showcase Portfolio
+
+This guide is the current application showcase map for Igniter. Use it when you
+want to evaluate the richer contracts-native examples as products, not only as
+small API snippets.
+
+The portfolio has five current applications:
+
+- Companion: ready-to-go personal assistant shell.
+- Lense: local codebase intelligence.
+- Chronicle: architecture decision review.
+- Scout: local-source research synthesis.
+- Dispatch: incident command and handoff.
+
+Each application is intentionally offline, one-process, and reproducible. They
+exercise `igniter-application`, `igniter-contracts`, `igniter-extensions`, and
+`igniter-web` through app-local structure. They do not define a public
+interactive app API.
+
+## What The Portfolio Proves
+
+The showcases demonstrate the same serious application loop:
+
+- app-owned services load local inputs, own mutable session state, and emit
+  deterministic evidence artifacts
+- one contracts-native graph computes the core analysis, readiness, or payload
+- command routes return app-local success/refusal results and record action
+  facts
+- one detached snapshot feeds the Web surface, `/events`, smoke output, and
+  manual inspection
+- `/report` or `/receipt` exposes an app-owned evidence artifact
+- smoke runs prove success, refusal, endpoint parity, and mutation boundaries
+
+This repetition is a copyable convention. It is not yet a framework contract,
+shared command result class, snapshot API, route DSL, marker DSL, UI kit,
+receipt/report API, or `Igniter.interactive_app` facade.
+
+## Showcase Matrix
+
+| Showcase | Purpose | Workflow | Packages exercised | Evidence artifact | Mutation boundary | Smoke | Manual server |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| Companion | Personal assistant shell for ordinary users. | Credentials setup -> reminders/trackers/countdowns -> body battery -> daily plan. | `igniter-application`, `igniter-contracts`, `igniter-extensions`, `igniter-ai`, `igniter-web`. | Setup state and deterministic daily summary. | SQLite app store; live AI remains explicit opt-in. | `ruby examples/application/companion_poc.rb` | `ruby examples/application/companion_poc.rb server` |
+| Lense | Codebase intelligence for a local Ruby project. | Scan project -> health findings -> guided issue session -> analysis report. | `igniter-application`, `igniter-contracts`, `igniter-extensions`, `igniter-web`. | `LenseAnalysisReceipt` through `/report`. | Reads an explicit sample project and proves no scanned-project mutation. | `ruby examples/application/lense_poc.rb` | `ruby examples/application/lense_poc.rb server` |
+| Chronicle | Decision compass for architecture proposals. | Proposal scan -> decision conflicts -> sign-off/refusal -> decision receipt. | `igniter-application`, `igniter-contracts`, `igniter-extensions`, `igniter-web`. | `DecisionReceipt` through `/receipt`. | Reads proposal/decision fixtures and writes runtime sessions/actions/receipts only to workdir. | `ruby examples/application/chronicle_poc.rb` | `ruby examples/application/chronicle_poc.rb server` |
+| Scout | Local-source research workspace. | Topic + local sources -> findings -> direction checkpoint -> research receipt. | `igniter-application`, `igniter-contracts`, `igniter-extensions`, `igniter-web`. | `ResearchReceipt` through `/receipt`. | Reads local source fixtures and writes runtime sessions/actions/receipts only to workdir. | `ruby examples/application/scout_poc.rb` | `ruby examples/application/scout_poc.rb server` |
+| Dispatch | Incident command and handoff. | Seeded incident events -> triage/routing -> assignment checkpoint -> incident receipt. | `igniter-application`, `igniter-contracts`, `igniter-extensions`, `igniter-web`. | `IncidentReceipt` through `/receipt`. | Reads incident/event/runbook/team fixtures and writes runtime sessions/actions/receipts only to workdir. | `ruby examples/application/dispatch_poc.rb` | `ruby examples/application/dispatch_poc.rb server` |
+
+## Package Capability Map
+
+Each showcase keeps its domain logic local while exercising the same package
+roles:
+
+| Showcase | Application capability | Contracts capability | Web capability |
+| --- | --- | --- | --- |
+| Lense | App composition, scan service, issue-session commands, snapshot, report endpoint. | `CodebaseHealthContract` computes health score, findings, evidence refs, and report metadata. | Mounted dashboard/workbench with `/events`, `/report`, feedback, counters, findings, and activity markers. |
+| Chronicle | Proposal/decision stores, conflict session commands, sign-off/refusal state, receipt endpoint. | `DecisionReviewContract` computes conflicts, required sign-offs, readiness, and receipt payload. | Mounted decision compass with `/events`, `/receipt`, feedback, conflict evidence, sign-off/refusal, and activity markers. |
+| Scout | Source library, research session commands, checkpoint state, receipt endpoint. | `ResearchSynthesisContract` computes findings, contradictions, checkpoint readiness, citations, and synthesis payload. | Mounted research workspace with `/events`, `/receipt`, feedback, source/provenance, checkpoint, and activity markers. |
+| Dispatch | Incident library, triage session commands, assignment/escalation state, receipt endpoint. | `IncidentTriageContract` computes severity, suspected cause, routing options, readiness, and receipt payload. | Mounted command center with `/events`, `/receipt`, feedback, event/citation, routing, assignment, and activity markers. |
+
+## Web Review Map
+
+Each richer showcase has one mounted Arbre surface. The surface reads one
+app-owned snapshot through `MountContext`; `app.rb` owns command routes,
+redirect feedback, `/events`, and the evidence endpoint.
+
+| Showcase | Mounted surface | Surface marker | Evidence endpoint | Manual review focus |
+| --- | --- | --- | --- | --- |
+| Lense | `web/lense_dashboard.rb` as `:lense_dashboard`. | `data-ig-poc-surface="lense_dashboard"` | `/report` | Scan summary, findings, evidence refs, issue-session actions, report validity, and no scanned-project mutation. |
+| Chronicle | `web/decision_compass.rb` as `:decision_compass`. | `data-ig-poc-surface="chronicle_decision_compass"` | `/receipt` | Proposal context, conflict evidence, sign-off/refusal state, decision receipt validity, and fixture no-mutation. |
+| Scout | `web/research_workspace.rb` as `:research_workspace`. | `data-ig-poc-surface="scout_research_workspace"` | `/receipt` | Topic, sources, citations, provenance, findings, contradictions, checkpoint state, research receipt validity, and fixture no-mutation. |
+| Dispatch | `web/command_center.rb` as `:command_center`. | `data-ig-poc-surface="dispatch_command_center"` | `/receipt` | Incident events, severity, routing rationale, assignment/escalation checkpoint, handoff receipt validity, and fixture no-mutation. |
+
+During manual review, inspect the browser page and these companion endpoints:
+
+- `/events` should agree with the visible state because both render from the
+  same detached app snapshot.
+- `/report` or `/receipt` should expose the app-owned evidence artifact when
+  the workflow reaches its checkpoint.
+- feedback should appear through query-string redirect state and render with
+  `data-ig-feedback` plus an app-local `data-feedback-code`.
+- recent activity should render from the same snapshot and use
+  `data-ig-activity` plus app-local action metadata.
+- command controls should expose app-local `data-action` values.
+- domain records and counters should expose explicit app-local `data-`
+  attributes for smoke and browser inspection.
+
+These markers are inspection seams, not a public marker DSL. Surface names,
+feedback codes, action names, endpoint labels, CSS direction, and panel
+grouping remain local to each showcase.
+
+## Run The Portfolio
+
+Run the full active examples catalog:
+
+```bash
+ruby examples/run.rb smoke
+```
+
+Run an individual showcase through the catalog:
+
+```bash
+ruby examples/run.rb run application/lense_poc
+ruby examples/run.rb run application/chronicle_poc
+ruby examples/run.rb run application/scout_poc
+ruby examples/run.rb run application/dispatch_poc
+```
+
+Run an individual showcase directly:
+
+```bash
+ruby examples/application/lense_poc.rb
+ruby examples/application/chronicle_poc.rb
+ruby examples/application/scout_poc.rb
+ruby examples/application/dispatch_poc.rb
+```
+
+Open a manual browser surface:
+
+```bash
+ruby examples/application/lense_poc.rb server
+ruby examples/application/chronicle_poc.rb server
+ruby examples/application/scout_poc.rb server
+ruby examples/application/dispatch_poc.rb server
+```
+
+Each server command prints a local URL. Server mode is example scaffolding for
+manual review, not production server behavior.
+
+Use in-process smoke runs as the default proof. Manual browser review is useful
+for evaluating the mounted screens, but the portfolio does not require browser
+automation, live transport, a production server, auth, persistence, scheduler,
+connectors, or LLM/provider integration.
+
+## Evidence To Inspect
+
+For each showcase, inspect three surfaces together:
+
+- HTML surface: the mounted `igniter-web` screen with stable app-local
+  `data-` markers.
+- `/events`: the text read model that mirrors the same app-owned snapshot.
+- `/report` or `/receipt`: the evidence artifact emitted by the app.
+
+The smoke output should include markers for:
+
+- the first successful command path
+- at least one refusal path
+- recent action facts
+- `/events` parity with the Web surface snapshot
+- receipt/report validity
+- fixture or target no-mutation
+
+## Application Structure Convention
+
+Use the showcase layout as a convention for new application experiments:
+
+- `app.rb` is the visible composition boundary.
+- `contracts/` contains the deterministic contracts-native graph.
+- `services/` owns loading, state, commands, and snapshots.
+- `reports/` owns receipt/report rendering when the workflow has evidence to
+  emit.
+- `web/` owns the local mounted surface.
+- the launcher script owns smoke and optional `server` mode.
+
+Keep domain names and repeated shapes local until package extraction is
+explicitly justified. In particular, keep command result classes, snapshot
+fields, feedback codes, route names, marker names, receipt payload keys,
+fixture schemas, thresholds, and readiness rules inside the app.
+
+For the detailed copyable convention, see
+[Interactive App Structure](./interactive-app-structure.md).
+
+## Legacy Boundary
+
+Legacy material is private/reference context, not the current onboarding path.
+Start from the current packages, this portfolio guide, the interactive app
+structure guide, and the four showcase READMEs:
+
+- [`examples/application/lense/README.md`](../../examples/application/lense/README.md)
+- [`examples/application/chronicle/README.md`](../../examples/application/chronicle/README.md)
+- [`examples/application/scout/README.md`](../../examples/application/scout/README.md)
+- [`examples/application/dispatch/README.md`](../../examples/application/dispatch/README.md)

data/docs/guide/cli.md

@@ -0,0 +1,70 @@
+# CLI
+
+This is the shortest guide to the current stack-first CLI surface.
+
+## Main Entry Points
+
+- `bin/start` — start the mounted stack runtime
+- `bin/start --node NAME` — start one local node profile
+- `bin/console` — open the igniter console
+- `bin/console --node NAME` — open console with one node profile selected
+- `bin/console --node NAME --eval '...'` — evaluate one expression and exit
+- `bin/dev` — start all local node profiles with prefixed output
+
+`bin/dev` also writes per-node logs to `var/log/dev/*.log`.
+
+## Scaffold Profiles
+
+`igniter-stack new` currently supports:
+
+- base profile by default
+- `--profile dashboard` for a mounted dashboard app at `/dashboard`
+- `--profile cluster` for a cluster-ready sandbox with node profiles and self-heal demo
+- `--profile playground` for a richer local lab scaffold
+
+Examples:
+
+```bash
+bin/igniter-stack new my_app
+bin/igniter-stack new my_hub --profile dashboard
+bin/igniter-stack new mesh_lab --profile cluster
+bin/igniter-stack new playgrounds/home-lab --profile playground
+```
+
+## Mental Model
+
+- `stack.rb` is the executable runtime surface
+- positional `app` means “run this one app directly”
+- `--node` means “boot the stack as this node profile”
+- `--console` means “load stack/app/runtime helpers into IRB”
+
+## Console Helpers
+
+Inside `bin/console`, these locals are available:
+
+- `stack`
+- `context`
+- `app`
+- `root_app`
+- `node`
+- `node_profile`
+- `deployment`
+- `runtime`
+- `mounts`
+- `mesh`
+- `stack_settings`
+
+Example:
+
+```bash
+bin/console --node seed --eval 'context.node_name'
+```
+
+## Built-In Help
+
+The runtime also exposes help directly:
+
+```bash
+bundle exec ruby stack.rb --help
+bundle exec ruby stack.rb --console --help
+```

data/docs/guide/cluster.md

@@ -0,0 +1,55 @@
+# Cluster
+
+Use this section when execution is no longer single-node and the network itself becomes part of the runtime.
+
+## Cluster Means
+
+- mesh membership and gossip
+- capability-based routing across peers
+- replication and distributed coordination
+- resilience, plasticity, and decentralized runtime behavior
+- cluster diagnostics and routing explainability
+
+The cluster layer should stay above `Embed` and `Application`. It is not the
+place to redefine the kernel.
+
+## Current First Reads
+
+- [Guide](../guide/README.md)
+- [Guide: How-Tos](../guide/how-tos.md)
+- [Dev: Cluster Target Plan](../dev/cluster-target-plan.md)
+
+## Supporting Reference
+
+- [Guide: Distributed Workflows](../guide/distributed-workflows.md)
+
+## Useful Supporting Docs
+
+- [Guide: Core Runtime Features](../guide/core-runtime-features.md)
+
+## Examples
+
+- [Examples index](../../examples/README.md)
+- cluster-oriented examples such as `cluster/incidents`,
+  `cluster/incident_workflow`, `cluster/mesh_diagnostics`,
+  `cluster/remediation`, and `cluster/routing`
+- [Playgrounds](../../playgrounds/README.md) for local-first cluster and home-lab experiments
+
+## Cluster Reading Heuristic
+
+- If the topic is about contracts or execution semantics without networking,
+  it probably belongs back in [Core](./core.md).
+- If the topic is about app boot/profile without network coordination, it
+  probably belongs in [App](./app.md).
+
+## Direction
+
+Current design direction:
+
+- `Cluster` is being reset as a contracts-native distributed runtime layer
+- it should sit above `Embed` and `Application`, not redefine either of them
+- new design work should follow the
+  [Cluster Target Plan](../dev/cluster-target-plan.md)
+
+Older cluster research and legacy notes are private working material under
+`playgrounds/docs/`, not public onboarding.

data/docs/guide/configuration.md

@@ -0,0 +1,31 @@
+# Configuration
+
+Use this index when the question is operational: boot shape, deployment, stack
+layout, or persistence.
+
+## Current Starting Points
+
+- [CLI](./cli.md)
+- [Application Capsules](./application-capsules.md)
+- [Deployment Modes](./deployment-modes.md)
+- [App](./app.md)
+
+## Runtime And Deployment Reference
+
+- [Deployment Modes](./deployment-modes.md)
+- [Credentials](./credentials.md)
+- [Store Adapters](./store-adapters.md)
+- [Application Capsules](./application-capsules.md)
+
+## Current Heuristic
+
+- Start embedded with `require "igniter"` when the host app already exists.
+- Move to `igniter-application` when Igniter becomes the runtime shape.
+- Move to `igniter-cluster` only when distribution is a real execution concern.
+
+## Project Shapes
+
+- [Examples](../../examples/README.md)
+- [Application Showcase Portfolio](./application-showcase-portfolio.md)
+- [Interactive App Structure](./interactive-app-structure.md)
+- [Playgrounds](../../playgrounds/README.md)

data/docs/guide/contract-class-dsl.md

@@ -0,0 +1,154 @@
+# Contract Class DSL
+
+Igniter contracts have two equal authoring forms:
+
+- block compilation for low-level embedding and generated graphs
+- class DSL for human-edited application code
+
+For a runnable path across contracts, examples, application showcases, and Lang,
+start with [Getting Started](./getting-started.md).
+
+Use the class form when a Rails/service/job author needs to read the contract as
+business logic.
+
+```ruby
+class PriceContract < Igniter::Contract
+  define do
+    input :order_total, type: :numeric
+    input :country, type: :string
+
+    compute :vat_rate, depends_on: [:country] do |country:|
+      country == "UA" ? 0.2 : 0.0
+    end
+
+    compute :gross_total, depends_on: %i[order_total vat_rate] do |order_total:, vat_rate:|
+      order_total * (1 + vat_rate)
+    end
+
+    output :gross_total
+  end
+end
+
+contract = PriceContract.new(order_total: 100, country: "UA")
+contract.result.gross_total
+contract.update_inputs(order_total: 150)
+contract.output(:gross_total)
+```
+
+## Why This Form Exists
+
+The block form is still the smallest kernel surface:
+
+```ruby
+compiled = Igniter::Contracts.compile do
+  input :amount
+  output :amount
+end
+```
+
+The class form adds the shape app code usually wants:
+
+- one contract per file
+- a compact `define do ... end` body
+- result readers such as `contract.result.gross_total`
+- `update_inputs` for repeated local runs
+- a stable class name that host layers can register, cache, reload, and call
+
+This is not a separate runtime. `Igniter::Contract` compiles and executes
+through `igniter-contracts`.
+
+## Callable Steps
+
+Use blocks for local logic and `call:` for existing service objects.
+
+```ruby
+class GrossTotal
+  def self.call(order_total:, vat_rate:)
+    order_total * (1 + vat_rate)
+  end
+end
+
+class PriceContract < Igniter::Contract
+  define do
+    input :order_total
+    input :vat_rate
+    compute :gross_total, depends_on: %i[order_total vat_rate], call: GrossTotal
+    output :gross_total
+  end
+end
+```
+
+Callable objects receive keyword arguments named after `depends_on`.
+
+## Result Shape
+
+The minimum reader surface is intentionally small:
+
+```ruby
+contract = PriceContract.new(order_total: 100, vat_rate: 0.2)
+
+contract.success?
+contract.failure?
+contract.outputs
+contract.output(:gross_total)
+contract.result.gross_total
+contract.to_h
+```
+
+Unknown result readers raise a clear `KeyError`.
+
+## Embed Hosts
+
+`igniter-embed` consumes contract classes without redefining the DSL:
+
+```ruby
+contracts = Igniter::Embed.configure(:shop) do |config|
+  config.cache = true
+  config.root "app/contracts"
+  config.contract PriceContract, as: :price_quote
+end
+
+result = contracts.call(:price_quote, order_total: 100, country: "UA")
+result.output(:gross_total)
+```
+
+Named contract classes can also be registered directly. The inferred name uses
+the last class segment, removes a trailing `Contract`, and snake-cases it:
+
+```ruby
+contracts.register(Billing::PriceContract)
+contracts.call(:price, order_total: 100, country: "UA")
+```
+
+The host layer owns naming, caching, reload hooks, and failure envelopes. The
+contract class owns the business graph.
+
+`config.root` identifies the host-local contract directory. It does not load
+files by itself. Automatic discovery is opt-in:
+
+```ruby
+contracts = Igniter::Embed.configure(:shop) do |config|
+  config.root "app/contracts"
+  config.discover!
+end
+```
+
+Discovery is useful for small scripts and experiments. For application boot,
+prefer explicit `config.contract SomeContract, as: :name` until you want a
+convention-driven loader.
+
+Discovery only registers named contract classes. Anonymous classes are ignored,
+explicit registrations win over discovered contracts with the same name, and
+duplicate discovered names raise a discovery error so hosts do not silently pick
+the wrong contract.
+
+## Design Pressure
+
+The class DSL removes most container ceremony from app-local contracts. The next
+ergonomics target is reducing repeated fail-fast and host registration boilerplate
+without hiding the business graph.
+
+## Related
+
+- [Getting Started](./getting-started.md)
+- [Igniter Lang Foundation](./igniter-lang-foundation.md)

data/docs/guide/core-runtime-features.md

@@ -0,0 +1,34 @@
+# Core Runtime Features
+
+Use this page for features that still belong near the embedded contracts
+kernel.
+
+## Current Shape
+
+- contract DSL and class DSL
+- graph compilation and validation
+- local execution
+- diagnostics and structured reports
+- explicit optional packs from `igniter-extensions`
+
+Optional features should be installed through explicit packs. Avoid hidden
+global activation and old `igniter/core/*` entrypoints in new public examples.
+
+## Heuristic
+
+Keep a feature near the embedded kernel when it is about computation semantics
+or local execution behavior.
+
+Move it upward when it needs:
+
+- app boot/profile lifecycle
+- web rendering or browser interaction
+- framework integration
+- distributed routing or placement
+
+## Reading Path
+
+- [Core](./core.md)
+- [API And Runtime](./api-and-runtime.md)
+- [Module System](../dev/module-system.md)
+- [`packages/igniter-extensions/README.md`](../../packages/igniter-extensions/README.md)