@jstn-sdk/rcs 0.1.7 → 0.1.8

package/docs/reference/agentic-platform-compatibility.md

@@ -0,0 +1,147 @@
+# Agentic Platform Compatibility
+
+RCS should be portable across agentic AI platforms, but **portability does not mean pretending every platform has the same runtime model as Codex**.
+
+The correct goal is:
+
+- one canonical authoring surface
+- one compatibility contract
+- multiple platform-specific delivery lanes
+
+That contract is now materialized in:
+
+- [`src/platform-targets/manifest.json`](../../src/platform-targets/manifest.json)
+- [`src/platform-targets/schema.ts`](../../src/platform-targets/schema.ts)
+- [`src/platform-targets/reader.ts`](../../src/platform-targets/reader.ts)
+
+## What stays canonical
+
+These are the source-of-truth surfaces inside this repo:
+
+- `skills/` — canonical workflow skills
+- `prompts/` — canonical prompt guidance for setup-owned native-agent generation
+- `src/agents/definitions.ts` — canonical native-agent role registry
+- `src/catalog/manifest.json` — canonical installability and alias/merged policy
+- `templates/AGENTS.md` — canonical orchestration brain template
+- `src/config/rcs-first-party-mcp.ts` and related config generators — canonical first-party MCP metadata
+
+Everything else should be an **emitted delivery surface** or an **adapter surface**.
+
+## Delivery lanes
+
+### 1. Codex native setup lane
+
+This is the deepest-supported lane today.
+
+It includes:
+
+- generated native agents under `.codex/agents/`
+- installed prompts under `.codex/prompts/`
+- installed skills under the selected setup scope
+- setup-owned runtime hooks
+- `.rcs/` runtime state
+
+This lane is driven by `rcs setup`.
+
+### 2. Codex plugin + marketplace lane
+
+This is the installable bundle lane today.
+
+It includes:
+
+- plugin bundle under `plugins/roblox-ai-os-creator-skills/`
+- marketplace metadata in `.agents/plugins/marketplace.json`
+- plugin-scoped skill discovery
+- plugin-scoped MCP/app companion metadata
+
+Important boundary:
+
+- the plugin bundle is **not** the full runtime setup
+- setup-owned prompts, native-agent TOMLs, and runtime hooks remain outside the plugin manifest
+
+### 3. Adapter lane for external platforms
+
+This is how non-Codex platforms should be integrated.
+
+Examples:
+
+- OpenClaw
+- Hermes
+- future Claude-oriented or marketplace-oriented bridges
+
+The rule is:
+
+- do not fork canonical skill/prompt/runtime truth into platform-specific ad hoc copies
+- add a platform adapter or delivery contract that maps canonical RCS surfaces into the target platform’s format
+
+## What “compatible with any agentic AI platform” should mean
+
+It should mean:
+
+- RCS authors once from canonical source surfaces
+- RCS can emit or adapt those surfaces for a target platform
+- each target gets the format it actually supports
+
+It should **not** mean:
+
+- every platform receives the exact same file layout
+- every platform gets Codex-only runtime semantics
+- plugin, marketplace, hooks, prompts, and native agents all collapse into one fake universal package
+
+## Platform model
+
+Use this mental model:
+
+- **Canonical source layer**: skills, prompts, registry, catalog, templates
+- **Delivery layer**: Codex native setup, Codex plugin bundle, marketplace package
+- **Adapter layer**: target-specific bridge for platforms with different runtime rules
+
+## Claude-style example
+
+For a Claude-like platform, the right question is not:
+
+- “Can we copy the Codex plugin/runtime shape into `.claude/`?”
+
+The right question is:
+
+- “Which canonical RCS surfaces should be delivered natively, and which must stay adapter-owned because the target platform does not share Codex runtime semantics?”
+
+That usually means:
+
+- skills may be portable
+- selected guidance may be portable
+- marketplace/package metadata may be portable
+- setup-owned native agents and runtime hooks are **not** automatically portable one-to-one
+
+## Marketplace example
+
+For a marketplace-oriented platform, the package should be treated as a delivery artifact:
+
+- emitted from canonical repo sources
+- versioned from canonical package/release metadata
+- validated against a platform-specific boundary contract
+
+Not as a second source of truth.
+
+## Current repo posture
+
+Today RCS is strongest in:
+
+- Codex native setup
+- Codex plugin/marketplace packaging
+- adapter-style compatibility lanes such as OpenClaw/Hermes
+
+It is **not yet** a finished universal emitter for every external agent platform.
+
+That is intentional. The repo should grow by adding **clean adapters/delivery contracts**, not by duplicating the product into platform-specific silos.
+
+## Concrete target lanes
+
+The current platform target manifest defines these concrete lanes:
+
+- `codex-native`
+- `codex-plugin`
+- `claude-like`
+- `marketplace-bundle`
+- `adapter-openclaw`
+- `adapter-hermes`

package/docs/reference/llm-provider-abstraction.md

@@ -0,0 +1,88 @@
+# LLM Provider Abstraction
+
+Status: canonical model- and API-agnostic provider layer for RCS runtime configuration.
+
+## Purpose
+
+RCS should treat LLM providers as interchangeable components, not permanent dependencies.
+
+That means:
+- model routing is separate from provider routing
+- provider configuration is explicit
+- fallback providers can be declared without rewriting core logic
+- OpenAI-compatible gateways, Anthropic-style gateways, or other future providers can be swapped in without redesigning the product surface
+
+## Core Principle
+
+RCS routes work by:
+1. workflow or role intent
+2. model lane
+3. provider selection
+
+The application should not have to change its core logic just because the backing provider changes.
+
+## Config Shape
+
+`.rcs-config.json` may now include:
+
+```json
+{
+  "providers": {
+    "openrouter": {
+      "base_url": "https://openrouter.ai/api/v1",
+      "api_format": "openai-compatible",
+      "env_key": "OPENROUTER_API_KEY",
+      "capabilities": ["chat", "reasoning"],
+      "label": "OpenRouter"
+    }
+  },
+  "routing": {
+    "default_provider": "openrouter",
+    "mode_providers": {
+      "forge": "openrouter"
+    },
+    "fallback_providers": ["openrouter"],
+    "mode_fallback_providers": {
+      "forge": ["openrouter"]
+    },
+    "hot_swap": true,
+    "failover": true
+  }
+}
+```
+
+## What This Enables
+
+- **Provider-agnostic routing** — use one model/provider abstraction without hard-wiring a single vendor into every workflow
+- **OpenAI-compatible gateways** — route through unified proxy formats where useful
+- **Mode-specific provider policies** — for example one provider for `forge`, another for `team`
+- **Fallback chains** — define ordered failover providers for runtime resilience
+- **Hot-swap intent** — document whether provider hot-swapping is considered part of the runtime policy
+
+## Important Clarification
+
+This layer is about **LLM/model provider routing**.
+
+It is **not** the same as:
+- `robloxstudio-mcp` live Studio transport
+- OpenClaw notifications/gateway delivery
+
+### OpenClaw
+
+OpenClaw is adjacent infrastructure:
+- useful for notifications/gateway automation
+- not the canonical LLM provider abstraction
+- should not be treated as the model-provider routing layer
+
+## Current Runtime Hooks
+
+Implemented runtime helpers live in:
+- `src/config/models.ts`
+
+They now support:
+- provider profile reads
+- default provider resolution
+- mode-specific provider resolution
+- fallback provider lists
+- hot-swap/failover flags
+- normalized active provider connection summaries

package/docs/reference/multi-agent-compatibility-architecture.md

@@ -0,0 +1,120 @@
+# Multi-Agent Compatibility Architecture
+
+RCS already ships a real multi-agent compatibility system, but in this repo it is split across **native agent definitions**, **catalog policy**, **native Codex TOML generation**, and **adapter targets**.
+
+This document names that architecture explicitly so contributors do not project an external `src/agents.ts` example onto the wrong files.
+
+## Canonical files
+
+- Native agent registry: [`src/agents/definitions.ts`](../../src/agents/definitions.ts)
+- Native-agent install policy: [`src/agents/policy.ts`](../../src/agents/policy.ts)
+- Native-agent config adapter/generator: [`src/agents/native-config.ts`](../../src/agents/native-config.ts)
+- Public catalog manifest: [`src/catalog/manifest.json`](../../src/catalog/manifest.json)
+- External adapter target contracts: [`src/adapt/contracts.ts`](../../src/adapt/contracts.ts)
+- External adapter target registry: [`src/adapt/registry.ts`](../../src/adapt/registry.ts)
+- CLI native-agent management: [`src/cli/agents.ts`](../../src/cli/agents.ts)
+- Native-agent verification: [`src/scripts/verify-native-agents.ts`](../../src/scripts/verify-native-agents.ts)
+
+## Core patterns
+
+### Registry pattern
+
+RCS uses **two registries**:
+
+- `AGENT_DEFINITIONS` in `src/agents/definitions.ts`
+- target descriptors in `src/adapt/registry.ts`
+
+Those registries keep agent and adapter metadata centralized instead of scattering role-specific logic through setup, runtime, and verification code.
+
+### Adapter pattern
+
+RCS does not expose prompt markdown or external target state directly.
+
+Instead:
+
+- `src/agents/native-config.ts` adapts prompt markdown plus `AgentDefinition` metadata into native Codex TOML files
+- `src/adapt/*` adapts target-specific runtime evidence such as OpenClaw or Hermes into a shared envelope/probe/status contract
+
+The rest of the system can therefore consume a stable RCS-owned shape rather than raw target-specific details.
+
+### Strategy pattern
+
+The compatibility layer applies strategy-like decisions through registry-backed metadata instead of giant conditionals:
+
+- `modelClass`, `posture`, and `routingRole` select native-agent instruction overlays and model resolution behavior
+- adapter target descriptors select target-specific capability reports while preserving a shared foundation contract
+- catalog `status` values such as `active`, `internal`, `alias`, and `merged` determine installability and canonical-target behavior
+
+### Plugin-style architecture
+
+RCS supports extension without rewriting the core native-agent installer:
+
+- add or adjust a native role in `AGENT_DEFINITIONS`
+- classify it in `src/catalog/manifest.json`
+- provide the matching prompt asset in `prompts/`
+- let `verify-native-agents` enforce the contract
+
+For external targets, add a target contract and registry descriptor under `src/adapt/*` without changing unrelated adapter lanes.
+
+## Supporting techniques
+
+### Configuration-driven design
+
+The compatibility layer is mostly declarative:
+
+- agent metadata is data-first in `AGENT_DEFINITIONS`
+- installability and canonical aliases are data-first in `src/catalog/manifest.json`
+- adapter capabilities are data-first in `TARGET_DESCRIPTORS`
+
+That keeps policy visible and reviewable.
+
+### Facade pattern
+
+RCS exposes small facade helpers over the registries instead of forcing consumers to walk raw objects:
+
+- `getAgent`
+- `listAgents`
+- `getAgentNames`
+- `getAgentsByCategory`
+- `getAgentsByPosture`
+- `getAgentsByRoutingRole`
+- `getInstallableNativeAgentNames`
+- `listAdaptTargets`
+- `getAdaptTargetDescriptor`
+
+### Canonical-boundary pattern
+
+RCS keeps ownership boundaries explicit:
+
+- prompt markdown is setup-owned source content under `prompts/`
+- generated native Codex agent TOML is emitted under `~/.codex/agents/` or `./.codex/agents/`
+- plugin manifests must **not** claim setup-owned `agents`, `prompts`, or `hooks`
+- adapter writes stay under `.rcs/adapters/<target>/...`
+
+This avoids duplication and prevents plugin/runtime surfaces from silently fighting over the same artifacts.
+
+## What this architecture is not
+
+This repo does **not** currently use the external example's exact shape:
+
+- no monolithic `src/agents.ts`
+- no `.agents/skills` universal-directory + symlink installer as the core native-agent mechanism
+- no per-agent `detectInstalled()` registry for dozens of third-party coding tools as the main compatibility layer
+
+RCS instead centers on:
+
+- native Codex agent-role generation
+- catalog-governed canonical/alias boundaries
+- adapter-target compatibility lanes such as OpenClaw and Hermes
+
+## Verification contract
+
+The architecture is guarded by tests and verification surfaces:
+
+- [`src/agents/__tests__/definitions.test.ts`](../../src/agents/__tests__/definitions.test.ts)
+- [`src/agents/__tests__/native-config.test.ts`](../../src/agents/__tests__/native-config.test.ts)
+- [`src/adapt/__tests__/foundation.test.ts`](../../src/adapt/__tests__/foundation.test.ts)
+- [`src/scripts/__tests__/verify-native-agents.test.ts`](../../src/scripts/__tests__/verify-native-agents.test.ts)
+- [`src/verification/__tests__/multi-agent-compatibility-architecture.test.ts`](../../src/verification/__tests__/multi-agent-compatibility-architecture.test.ts)
+
+If you change the compatibility architecture, update the doc and the contract tests together.

package/docs/reference/rcs-config-schema-routing.md

@@ -29,6 +29,8 @@ Current code recognizes these top-level `.rcs-config.json` keys:
 | --- | --- | --- |
 | `env` | Object of non-empty string values | Fallback environment values for model routing and helper launch paths. Model-related supported keys are listed below. |
 | `models` | Object of non-empty string values | Mode defaults and low-complexity model aliases. Supported model-routing keys are listed below. |
+| `providers` | Object | Provider profiles for model/API-agnostic routing (`base_url`, `api_format`, `env_key`, `capabilities`, `label`). |
+| `routing` | Object | Default provider, mode-specific provider mapping, fallback provider chains, and hot-swap/failover flags. |
 | `notifications` | Object | Notification transports, profiles, templates, cooldowns, replies, and OpenClaw/custom aliases. See the notification summary below and the OpenClaw guide for full examples. |
 | `stopHookCallbacks` | Legacy object | Backward-compatible legacy session-end notification config for `telegram` and `discord`; prefer `notifications`. |
 | `promptRouting` | `{ "triage": { "enabled": boolean } }` | Enables/disables advisory triage prompt routing. Missing key defaults to enabled; malformed shape fails closed to disabled. |
@@ -251,6 +253,7 @@ If behavior does not match your config, first confirm whether you are in user or
 ## Related docs and source surfaces
 
 - Notification and OpenClaw config: [`docs/openclaw-integration.md`](../openclaw-integration.md)
+- Provider abstraction: [`docs/reference/llm-provider-abstraction.md`](./llm-provider-abstraction.md)
 - Project wiki config: [`docs/reference/project-wiki.md`](./project-wiki.md)
 - Model routing source: `src/config/models.ts`
 - Notification config source: `src/notifications/config.ts`, `src/notifications/types.ts`, `src/notifications/hook-config-types.ts`

package/docs/reference/roblox-mcp-reference-layer.md

@@ -0,0 +1,75 @@
+# Roblox MCP Reference Layer
+
+Status: canonical external reference-source policy for Roblox-facing RCS work.
+
+## Purpose
+
+RCS has two different MCP/reference layers:
+
+1. **First-party RCS MCP servers**
+   - local stdio servers for state, memory, code-intel, trace, and wiki
+2. **External Roblox reference sources**
+   - official Creator Docs
+   - serverless `gitmcp.io` mirrors
+   - Roblox-specific skill repositories
+   - implementation corpora
+
+This file defines how those external sources should be used.
+
+## Canonical Source Order
+
+### Tier 1: Official platform truth
+
+Use these first when the question is about correctness, APIs, platform behavior, or Creator Hub rules:
+
+- `https://github.com/Roblox/creator-docs`
+- `https://gitmcp.io/Roblox/creator-docs`
+
+These define the canonical platform truth.
+
+### Tier 2: High-signal Roblox implementation references
+
+Use these to improve implementation awareness after the official baseline is grounded:
+
+- `https://github.com/sentinelcore/roblox-skills`
+- `https://gitmcp.io/sentinelcore/roblox-skills`
+- `https://github.com/greedychipmunk/agent-skills/tree/main/roblox-game-developer`
+- `https://github.com/omer-metin/skills-for-antigravity/tree/main/skills/roblox-development`
+- `https://github.com/dig1t/skills`
+- `https://github.com/Corecii/Devprod`
+- `https://gitmcp.io/Corecii/Devprod`
+
+### Tier 3: Raw script corpora and broad pattern mining
+
+Use these only as inspiration or anti-pattern review, never as canonical truth:
+
+- `https://github.com/retpirato/Roblox-Scripts`
+- `https://gitmcp.io/retpirato/Roblox-Scripts`
+- `https://gitmcp.io/frosteen/Roblox_LUA_Weapon_Scripts`
+- `https://gitmcp.io/uhub/awesome-lua`
+- `https://gitmcp.io/LewisJEllis/awesome-lua`
+- `https://gitmcp.io/forhappy/awesome-lua`
+- `http://lua-users.org/wiki/SampleCode`
+
+## Usage Rules
+
+- Official Roblox docs decide correctness.
+- Skill repositories improve implementation strategy, workflow framing, and checklist quality.
+- Raw script corpora are weak signals only; treat them as inspiration or anti-pattern mining.
+- Never present a third-party script repository as if it overrides official Roblox platform guidance.
+- Prefer the serverless `gitmcp.io` mirror when fast MCP-style browsing helps, but do not confuse the mirror with official product ownership.
+
+## RCS Fit
+
+This repo should treat the layer like this:
+
+- **RCS first-party MCP** = local runtime/state/control plane
+- **Creator Docs / `gitmcp.io`** = external Roblox platform truth
+- **Roblox skill repos** = implementation guidance and workflow references
+- **Raw script corpora** = non-canonical pattern support only
+
+## Template
+
+Reference inventory shipped with the repo:
+
+- `templates/roblox/reference-sources.md`

package/docs/reference/roblox-pre-action-protocol.md

@@ -45,10 +45,18 @@ Priority 1: canonical platform truth
 - `https://gitmcp.io/Roblox/creator-docs`
 
 Priority 2: high-signal implementation references
+- `https://github.com/sentinelcore/roblox-skills`
 - `https://gitmcp.io/retpirato/Roblox-Scripts`
 - `https://gitmcp.io/sentinelcore/roblox-skills`
-- `https://gitmcp.io/frosteen/Roblox_LUA_Weapon_Scripts`
+- `https://github.com/greedychipmunk/agent-skills/tree/main/roblox-game-developer`
+- `https://github.com/omer-metin/skills-for-antigravity/tree/main/skills/roblox-development`
+- `https://github.com/dig1t/skills`
+- `https://github.com/Corecii/Devprod`
 - `https://gitmcp.io/Corecii/Devprod`
+
+Priority 3: raw script and corpus support
+- `https://github.com/retpirato/Roblox-Scripts`
+- `https://gitmcp.io/frosteen/Roblox_LUA_Weapon_Scripts`
 - `https://gitmcp.io/uhub/awesome-lua`
 - `https://gitmcp.io/LewisJEllis/awesome-lua`
 - `https://gitmcp.io/forhappy/awesome-lua`
@@ -61,11 +69,15 @@ Priority 3: dataset and corpus support
 - `https://datasets-server.huggingface.co/splits?dataset=TorpedoSoftware%2FRoblox-Luau-Reasoning-v1.0`
 - `https://huggingface.co/datasets/bartholomort/lua-obfuscator-corpus`
 
-Rules:
+Reference policy:
 - official Roblox docs define correctness
-- repos improve implementation awareness only
+- Roblox skill repos improve implementation awareness only
 - datasets are weak pattern support only
 
+Canonical reference-layer policy is documented in:
+- `docs/reference/roblox-mcp-reference-layer.md`
+- `templates/roblox/reference-sources.md`
+
 ## Phase 2: Understanding Synthesis
 
 Before implementation, answer:

package/docs/release-notes-v0.1.8.md

@@ -0,0 +1,24 @@
+# Roblox Creator Skills v0.1.8
+
+## Summary
+
+`v0.1.8` is the MCP/reference-layer activation release after the `0.1.7` docs and localization hardening line. It makes the GitMCP Roblox reference sources part of the default managed Codex setup, documents the activation split more clearly, and adds the tests needed to keep that default layer stable.
+
+## What changed
+
+- Default managed Codex config now includes:
+  - `creator_docs`
+  - `roblox_skills`
+  - `devprod_docs`
+  - `roblox_scripts_corpus`
+- Added canonical docs for the Roblox MCP reference layer
+- Added a shipped reference-source template inventory
+- Clarified in README and localized READMEs that:
+  - `rcs mcp-serve` is for first-party local RCS MCP servers
+  - GitMCP Roblox references should stay enabled by default
+  - `robloxstudio-mcp` remains a manual live Studio bridge
+
+## Verification
+
+- `npm run build`
+- `node --test dist/config/__tests__/roblox-reference-mcp.test.js dist/config/__tests__/generator-idempotent.test.js dist/verification/__tests__/roblox-mcp-reference-layer.test.js dist/verification/__tests__/robloxstudio-mcp-compatibility.test.js`

package/docs/wiki/Contributing.md

@@ -0,0 +1,45 @@
+# Contributing Wiki
+
+This page complements the repository root [CONTRIBUTING.md](../../CONTRIBUTING.md).
+
+## Fastest way to start
+
+1. Read the root [README](../../README.md).
+2. Run the local setup flow.
+3. Look for issues labeled `good first issue` or `help wanted`.
+4. Pick a small, self-contained task before touching larger workflow/runtime surfaces.
+
+## What maintainers should optimize for
+
+- a newcomer should be able to install, build, and smoke-test the repo in a few minutes
+- issue descriptions should include clear reproduction or acceptance criteria
+- docs, localization, wiki, and QA contributions count as real contributions
+- roadmap items should be broken into slices that can be finished without deep repo archaeology
+
+## Accepted contribution types
+
+- code and tests
+- docs and onboarding fixes
+- localization updates
+- issue triage and reproduction refinement
+- release notes and changelog cleanup
+- contributor-experience improvements
+
+## Mentorship posture
+
+- explain repo-local vocabulary when it is not obvious
+- redirect contributors to the right doc instead of assuming they already know the surface
+- prefer scoped guidance over vague “needs more work” reviews
+- keep review feedback factual and actionable
+
+## Labels that matter
+
+- `good first issue`
+- `help wanted`
+- `docs`
+- `localization`
+- `wiki`
+- `contributor experience`
+- `release`
+
+See [Good first issues and labels](./Good-First-Issues.md).

package/docs/wiki/Good-First-Issues.md

@@ -0,0 +1,44 @@
+# Good First Issues and Labels
+
+This page defines the maintainer standard for contributor-friendly task shaping.
+
+## Required labels
+
+- `good first issue` — small, safe, self-contained task with explicit acceptance criteria
+- `help wanted` — useful task that is open to outside contribution, but may require more repo context
+- `docs` — documentation surface
+- `localization` — translation or locale-sync work
+- `wiki` — contributor wiki or runtime wiki documentation surface
+- `contributor experience` — onboarding, templates, setup, or workflow ergonomics
+
+## What qualifies as a good first issue
+
+- one surface or subsystem
+- no hidden cross-repo dependency
+- clear reproduction or acceptance criteria
+- easy local verification path
+- no risky release, auth, or multi-runtime migration work
+
+## Good first issue examples in this repo
+
+- clarify a Roblox-first prompt or skill example
+- improve docs or setup wording
+- sync README locale drift after a root README change
+- add a missing focused test for a small contract
+- fix a small CLI/help text mismatch
+- tighten release notes or contributor guidance
+
+## What should not be labeled good first issue
+
+- large runtime refactors
+- release workflow surgery without a focused scope
+- tmux/team-state concurrency work with unclear blast radius
+- broad prompt taxonomy rewrites
+- changes that require maintainer-only credentials or environment access
+
+## Maintainer checklist before applying the label
+
+- task is broken down enough to fit in one PR
+- expected files are named
+- verification path is stated
+- hidden blockers are removed or called out

package/docs/wiki/Home.md

@@ -0,0 +1,35 @@
+# Contributor Wiki
+
+This is the contributor-facing wiki source for `JustineDevs/roblox-ai-os`.
+
+It is **not** the same thing as the local runtime wiki under `.rcs/wiki/`.
+Use this wiki for community guidance, roadmap context, issue triage, and release operations.
+
+## Start here
+
+- [Contributing guide](./Contributing.md)
+- [Good first issues and labels](./Good-First-Issues.md)
+- [Roadmap](./Roadmap.md)
+- [Release playbook](./Release-Playbook.md)
+
+## What this wiki is for
+
+- lowering the barrier to first contribution
+- giving contributors a stable place to understand priorities
+- showing maintainers how to label and scope newcomer-friendly work
+- documenting release and update flows without forcing people to reverse-engineer workflow files
+
+## Maintainer expectations
+
+- keep issues small, explicit, and easy to test
+- use `good first issue` and `help wanted` labels deliberately
+- respond quickly when a contributor asks for clarification
+- thank contributors in release notes, README acknowledgements, or follow-up docs when their work materially lands
+- accept non-code contributions such as docs, localization, QA, roadmap refinement, and issue triage
+- use an All Contributors-style mindset so contribution credit is not limited to code
+
+## Source of truth
+
+- Canonical public entry point: [../../README.md](../../README.md)
+- Contributor workflow contract: [../../CONTRIBUTING.md](../../CONTRIBUTING.md)
+- Roadmap source for contributor planning: [./Roadmap.md](./Roadmap.md)