suaveplan/openspec/templates/proposal.md

Package: @suaveplan/<pkg> Status: PROPOSED Type: <new-package | feature | bug-fix | spec-conformance | refactor>

Why

<2–4 sentences explaining the motivation. What problem does this solve? What broke or is broken without it? Cite incidents, audits, or user requests.>

What changes

<Bullet list of every public-surface change. New exports, new behaviors, modified signatures, removed APIs. Be exhaustive — anything not listed here will be missed at review time.>

• ADDED: <symbol> —
• MODIFIED: <symbol> —
• REMOVED: <symbol> — <why; link to deprecation notice>

Out of scope

<Bullet list of things explicitly NOT in this change, with reason. This prevents scope drift and gives reviewers a clear boundary.>

• —

Source mapping

REQUIRED for any package migrated from ../suaveplan/. Delete this entire section if the package is genesis-original (no enterprise/<pkg>.md exists).

This change derives from ../suaveplan/enterprise/<pkg>.md.

Requirement	Source lines	Notes
	L-L	<verbatim / reworded / extended>

Requirements with no source line

Requirement	Justification
	<why it's added in genesis above the source baseline>

Verification approach

<How will every requirement be verified? List the test files that will exist after this change ships, grouped by requirement. Every requirement in the spec delta must have a **Verified by:** line pointing at concrete it(...) titles in these files.>

• src/<feature>/<feature>.test.ts — covers requirements
• src/<feature>/<feature>.spec-conformance.test.ts — pins type-level / observability / strict-mode scenarios for requirements
• tests/dep-graph.test.ts — pins dependency invariants

Migration impact

<For changes that modify or remove existing public surface: list every consumer in the monorepo (grep @suaveplan/<pkg> in other packages) and how they're affected. For new packages or pure additions, write "None — additive only.">