chore - add inspectability prompts to the RFC template

[dannymeijer]

Area

• Documentation
• Tooling (CLI/formatter/test runner)

Summary

Add explicit inspectability / no-hidden-magic prompts to the Incan RFC template so new features describe how their behavior is surfaced to users, tools, editors, CI, and agents.

The goal is not extra bureaucracy. The goal is to make sure ergonomic language and stdlib features leave durable evidence: metadata, manifests, diagnostics, generated output, provenance, or inspection commands. A feature should not be considered designed if the only way to understand it is to read compiler internals or infer behavior from generated Rust.

Scope

• In scope:

  • Update workspaces/docs-site/docs/RFCs/TEMPLATE.md with a short inspectability checklist or section.
  • Include prompts such as:
    • What artifact or metadata exposes this behavior?
    • What command or tooling path inspects it?
    • What diagnostic fires when it is invalid?
    • What source span/provenance anchors it?
    • What generated code, manifest, or report proves what happened?
    • Which behavior is intentionally not implicit?
  • Add examples in contributor docs or the template comment where useful.
  • Keep the section concise enough that small RFCs can answer it without ceremony.

• Out of scope:

  • Retrofitting every existing RFC in one pass.
  • Requiring every feature to add a new CLI command.
  • Making machine-readable artifacts mandatory for tiny syntax clarifications where an existing artifact already covers the behavior.

• Risks:

  • The template can become too heavy if the prompts are verbose.
  • Authors may cargo-cult answers unless the section asks for concrete inspection surfaces.

Plan

1. Edit the RFC template with a compact inspectability section.
2. Include a few concrete examples in the section or nearby contributor guidance:
   • route decorators should appear in runtime manifests;
   • derives should appear in checked metadata or generated output inspection;
   • capability packs should expose dry-run mutation plans;
   • generated files should carry provenance;
   • stdlib host access should be visible through capability metadata when that layer exists.
3. Run the docs build or a targeted docs check if the template participates in the docs site.

Done when

• The RFC template prompts authors to name the inspection/metadata/diagnostic/provenance surface for new behavior.
• The prompts are concise and actionable.
• The change does not require retroactive edits to all existing RFCs.
• Docs build or the relevant local check passes.

[dannymeijer]

Triage note: this supports the same inspectability direction, but it does not need to block 0.4. It can potentially target v0.5 unless the RFC template update is tiny and can land opportunistically without taking time from the install/starter/demo/inspection path.