Prompt: Discover RFC Suite Shape

Use this prompt before projects/PROMPT-GENERATE-PROJECT-PACK.md when a source corpus exists but the RFC suite boundaries have not been fixed yet.

Before sending this prompt, prepare:

• a concrete system or project name
• the authoritative source corpus to analyze: implementation repos, standards text, official docs, schemas, traces, captures, fixtures, or exported artifacts
• any informative/background material that helps orientation but does not outrank the authoritative corpus
• any observed runtime or interoperability surfaces that reveal the system's real structure
• the authority rule to apply when sources disagree, or an explicit unknown if the harness must infer and justify one

Required substitutions and context:

• replace <system-name> with the real project or system name
• attach or preload the authoritative and informative materials named below
• do not ask this prompt to scaffold files; its job is discovery and suite design only

Expected result and next step:

• this prompt must return a reusable suite-discovery brief, not a pack scaffold
• the final section must be a structured Pack scaffold inputs block that can be copied into projects/PROMPT-GENERATE-PROJECT-PACK.md with minimal rewriting
• after reviewing the suite decision, use that Pack scaffold inputs section to drive pack generation

You are designing the smallest clean RFC suite needed to encapsulate a real system before any project pack is scaffolded.

System under analysis: `<system-name>`

Load these project inputs before deciding document boundaries:
- authoritative source corpus: `<implementation repos, standards text, official docs, observed bytes, traces, schemas, datasets, exported artifacts, or equivalent>`
- informative/background material: `<orientation notes, explainer docs, wiki pages, prior drafts, blog posts, issue threads, or equivalent>`
- observed system structure: `<runtime surfaces, captures, APIs, wire traces, command behavior, exported files, interoperability evidence, or equivalent>`
- authority rule when sources disagree: `<implementation wins over docs | standards text wins | observed output breaks ties | unknown, infer and justify>`

Your job is analysis and boundary design, not drafting RFC prose and not scaffolding repository files.

## Decision standard

Identify the system's core:
- algorithms that define interoperable behavior
- processes or state transitions that implementations must reproduce
- formats, schemas, or artifacts that must be parsed or produced
- protocols or message exchanges that cross a system boundary
- roles or actors whose responsibilities change the normative behavior
- terminology that needs one clear owning document

Then cluster those findings into the smallest clean RFC suite that lets a competent reader understand, implement, validate, and review the system without duplicated ownership.

Prefer fewer documents unless a split clearly improves one or more of these:
- clean ownership of a normative subject
- separable clean-room implementability
- reduced cross-document duplication
- clearer review and validation boundaries
- reuse of one format/protocol/algorithm by another document

Do not create standalone RFCs for material that should remain subordinate, such as:
- deployment guidance
- operator runbooks
- UI behavior
- implementation-local helper code
- examples or fixtures that exist only to illustrate another document
- performance tuning, product positioning, history, or narrative background
- security or IANA text that belongs inside another document unless there is a real independent registries/security surface that demands its own specification

## Required analysis steps

1. Inventory the system's normative surfaces from the loaded materials.
2. Distinguish authoritative behavior from explanatory or incidental material.
3. Identify the core algorithms, processes, formats, protocols, and roles.
4. Propose candidate document boundaries.
5. Merge or delete weak candidate documents until the suite is minimal but still clean.
6. Name explicit non-goals and subordinate topics that should not become their own RFC.
7. Assign dependencies, terminology ownership, and required clean-room capabilities for each surviving document.
8. Produce a final output that maps directly onto the input headings expected by `projects/PROMPT-GENERATE-PROJECT-PACK.md`.

## Required output shape

Return exactly these sections.

### 1. System core summary
- short charter: what the system fundamentally does
- authoritative surfaces actually used
- observed/runtime surfaces actually used
- authority rule applied
- one-paragraph explanation of what makes this system worth specifying

### 2. Normative surface inventory
Provide a compact table with one row per important surface:
- surface
- type: algorithm | process | format | protocol | role | terminology domain
- why it matters normatively
- likely owning document
- source anchors/evidence used to identify it

### 3. RFC suite recommendation
State:
- recommended suite size
- recommended deliverables list
- why this is the smallest clean suite
- rejected candidate documents and why they should stay dependent, merged, or out of scope

### 4. Document boundary table
For each recommended document, provide:
- working short name
- proposed title
- normative heart section name
- owns
- explicitly does not own
- depends on
- depended on by
- required clean-room capabilities
- key edge cases or review traps

### 5. Cross-document rules
State:
- terminology owners
- cross-document dependency rules
- section-to-source routing notes
- suite-wide in-scope topics
- suite-wide out-of-scope topics
- open metadata questions that pack generation cannot infer safely

### 6. Pack scaffold inputs
Return a final structured block using the following headings and field names so it can feed `projects/PROMPT-GENERATE-PROJECT-PACK.md` directly.

#### 1. Project identity and suite shape
- project directory name:
- project title:
- suite/documents:
- intended deliverables:
- short charter:

#### 2. Normative scope and boundaries
- in scope:
- out of scope:
- cross-document boundaries:
- required clean-room capabilities:

#### 3. Authoritative corpus and evidence routing
- authoritative source corpus:
- informative/background material:
- runtime or observed-evidence surfaces:
- authority rule when sources disagree:
- section-to-source routing notes:

#### 4. Project-specific references and dependencies
- normative references:
- informative references:
- internal dependencies:
- terminology owners:
- citation hygiene exceptions, if any:

#### 5. Front-matter inputs that remain project-specific
- per-document titles:
- authors/editors and affiliations:
- stream / submission type / intended status:
- abstract anchors:
- provenance or special boilerplate rules:
- metadata overrides to inherited defaults:

#### 6. Planned briefs
List the proposed `briefs/<name>.md` files and for each one provide:
- document owned
- scope
- normative heart
- dependencies
- exclusions
- edge cases

#### 7. Optional examples or staged support material
- example seeds needed:
- if yes, files to create under `examples/`:
- staged support material under `references/`:

## Guardrails
- Do not scaffold files or emit a repository tree.
- Do not propose extra documents just to mirror implementation modules.
- Do not hide uncertainty; mark unresolved metadata or naming questions explicitly.
- Do not invent authorities that were not present in the loaded materials.
- If one document can cleanly own a topic, prefer that over splitting it into a second RFC.
- If a topic only exists to support another document's implementability, keep it dependent unless separation is clearly justified.