@geraldmaron/construct 1.0.0

package/templates/docs/adr.md

@@ -0,0 +1,27 @@
+# ADR-{NNN}: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Status**: proposed | accepted | superseded | deprecated
+- **Deciders**: {names}
+- **Supersedes**: {ADR-NNN or none}
+
+## Context
+<!-- The forces at play. What is true today that makes a decision necessary? What constraints bound the space? -->
+
+## Decision
+<!-- The position taken, in one or two sentences. State it as a commitment, not a proposal. -->
+
+## Rationale
+<!-- Why this decision over the alternatives. The load-bearing reasons. -->
+
+## Consequences
+<!-- What becomes easier and what becomes harder once this is in effect. Include second-order effects. -->
+
+## Alternatives considered
+<!-- Other options and the specific reason each was rejected. One paragraph per alternative. -->
+
+## Reversibility
+<!-- Is this a one-way or two-way door? What would it take to reverse? When would we revisit? -->
+
+## References
+<!-- Prior ADRs, PRDs, research, tickets, discussions. -->

package/templates/docs/backlog-proposal.md

@@ -0,0 +1,26 @@
+# Backlog Proposal: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Target system**: Jira | Linear | GitHub Issues | other
+- **Status**: proposed | approved | applied | rejected
+
+<!--
+Use before writing to external issue trackers. The proposal is safe to generate
+autonomously; applying it requires explicit approval.
+-->
+
+## Source evidence
+<!-- Evidence brief, PRD, customer notes, tickets, or research supporting the proposal. -->
+
+## Proposed changes
+<!-- Table: create/update, target issue if any, title, rationale, evidence, acceptance criteria. -->
+
+## Duplicate and conflict check
+<!-- Existing issues or docs that may already cover this work. -->
+
+## Approval request
+<!-- The exact external writes requested. Include safe default if approval is not granted. -->
+
+## Application log
+<!-- Filled only after approval and execution. Include issue links and timestamps. -->

package/templates/docs/customer-profile.md

@@ -0,0 +1,34 @@
+# Customer Profile: {customer}
+
+- **Updated**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: active | inactive | archived
+
+<!--
+Profiles are additive memory. Do not delete history unless the user explicitly
+asks for cleanup. Keep facts tied to source evidence.
+-->
+
+## Snapshot
+<!-- One paragraph. Who this customer is, what they use the product for, and why they matter to the current work. -->
+
+## Environment
+<!-- Stack, tools, integrations, scale, constraints, and relevant operating model. -->
+
+## Active pain points
+<!-- Current friction, with source links or dates. Distinguish severe blockers from preferences. -->
+
+## Open asks
+<!-- Table: ask, first raised, times mentioned, source, linked issue, status. -->
+
+## Key contacts
+<!-- Roles and responsibilities. Avoid unnecessary personal data. -->
+
+## Product areas
+<!-- Areas of the product this customer touches or influences. -->
+
+## Evidence links
+<!-- Notes, tickets, calls, Slack threads, PRDs, or research tied to this customer. -->
+
+## Change log
+<!-- Dated additions. Preserve history so future synthesis can see how the account evolved. -->

package/templates/docs/evidence-brief.md

@@ -0,0 +1,37 @@
+# Evidence Brief: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | reviewed
+
+<!--
+Use before writing a PRD, Meta PRD, PRFAQ, or backlog proposal. This artifact
+keeps source evidence separate from product decisions.
+
+Write in short paragraphs with compact tables where useful. Use bullets only for
+source lists or grouped findings. Keep em dashes rare.
+-->
+
+## Decision this evidence informs
+<!-- One paragraph. What decision, document, or workflow this evidence will support. -->
+
+## Evidence threshold
+<!-- State the minimum signal needed to proceed. Example: two independent customers, three repeated mentions, or one severe enterprise blocker. -->
+
+## Sources
+<!-- Table: source, date, customer or actor, link/path, confidence. -->
+
+## What we observed
+<!-- Factual observations only. Separate direct evidence from interpretation. -->
+
+## Patterns
+<!-- Synthesized themes across sources. Include strength of signal and counter-evidence. -->
+
+## Open asks
+<!-- Customer or stakeholder asks that are not yet committed requirements. -->
+
+## Confidence
+<!-- High, medium, or low. Explain what would raise or lower confidence. -->
+
+## Recommendation
+<!-- Proceed to PRD, write signal brief, gather more evidence, or close as not actionable. -->

package/templates/docs/incident-report.md

@@ -0,0 +1,46 @@
+# Incident Report: {title}
+
+- **Incident ID**: {INC-NNNN}
+- **Date**: {YYYY-MM-DD}
+- **Severity**: SEV-1 | SEV-2 | SEV-3
+- **Duration**: {start} → {end} ({total})
+- **Authors**: {names}
+- **Status**: draft | final
+
+## Summary
+<!-- Two to four sentences. What happened, who was affected, how it was resolved. Blameless tone. -->
+
+## Impact
+<!-- Users affected, requests failed, revenue lost, data integrity consequences. Quantify. -->
+
+## Timeline
+<!-- Times in UTC. Key events: detection, diagnosis, mitigation, resolution, all-clear. One line per event. -->
+
+| Time (UTC) | Event |
+|------------|-------|
+| {HH:MM}    | {what happened or what was done} |
+
+## Root cause
+<!-- The underlying cause, not just the proximate trigger. The five-whys, condensed. -->
+
+## Contributing factors
+<!-- Conditions that made the incident possible, worse, or harder to resolve. Include process gaps, not just code. -->
+
+## What went well
+<!-- Detection, response, communication, tooling. Keep this honest. -->
+
+## What went poorly
+<!-- Be specific. Blameless, not blameless-to-the-point-of-vague. -->
+
+## Corrective actions
+<!-- Each action: owner, deadline, ticket link. Prefer systemic fixes over "be more careful". -->
+
+| Action | Owner | Deadline | Ticket |
+|--------|-------|----------|--------|
+| {what} | {who} | {date}   | {link} |
+
+## Lessons learned
+<!-- What this incident revealed about the system or the organization. -->
+
+## References
+<!-- Logs, dashboards, traces, related incidents, PRs that caused or fixed the issue. -->

package/templates/docs/memo.md

@@ -0,0 +1,27 @@
+# Memo: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+- **Audience**: {who this is for}
+- **Decision requested**: yes | no
+
+## TL;DR
+<!-- Three to five sentences. If the reader reads nothing else, what do they need to know? Lead with the recommendation. -->
+
+## Context
+<!-- Why now? What changed? What does the reader need to understand before the argument makes sense? -->
+
+## Argument
+<!-- The case. Walk through the reasoning in the order that makes the conclusion inevitable. Cite evidence. -->
+
+## Recommendation
+<!-- What you are asking the reader to agree to or decide. Concrete. Actionable. -->
+
+## Risks and tradeoffs
+<!-- What could go wrong with the recommendation. What you are giving up. What a reasonable dissenter would say. -->
+
+## Decision requested
+<!-- Exactly what you need from the reader: approval, input on a specific question, or FYI only. Name the deadline. -->
+
+## Appendix
+<!-- Supporting data, alternatives considered, references. Optional. -->

package/templates/docs/meta-prd.md

@@ -0,0 +1,56 @@
+# Meta PRD: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | in-review | approved | shipped | deprecated
+
+<!--
+Use this when the subject is the product operating system itself: an agent workflow,
+document standard, evidence pipeline, evaluation loop, template family, governance
+process, or internal product intelligence capability.
+
+A normal PRD defines what a product capability must do for users. A Meta PRD defines
+how the organization decides, documents, validates, and improves the product work.
+
+Write with a balance of structured paragraphs, compact tables, and selective bullets.
+Avoid a wall of bullets. Keep em dashes rare; prefer commas, periods, or parentheses.
+-->
+
+## Purpose
+<!-- One or two paragraphs. What product practice or system this Meta PRD improves, and why that matters now. -->
+
+## Operating problem
+<!-- Describe the failure mode in the current process. Name who feels it, how often, and what breaks downstream. -->
+
+## Scope
+<!-- What part of the product operating system changes. Include the teams, agents, templates, workflows, tools, or decision points affected. -->
+
+## Principles
+<!-- A short list of durable rules this system must preserve. Keep each principle testable enough to guide tradeoffs. -->
+
+## Inputs and evidence
+<!-- What evidence the system consumes: customer notes, interviews, traces, Jira issues, PRDs, research, analytics, support tickets, or prior decisions. State minimum evidence thresholds where useful. -->
+
+## Workflow requirements
+<!-- Numbered requirements for the process or agent workflow. Use MR-1, MR-2, etc. Each requirement should be observable in generated artifacts, workflow state, or tool behavior. -->
+
+## Document standards
+<!-- Required sections, tone, evidence rules, citation rules, formatting constraints, and anti-patterns. State how this differs from a normal PRD. -->
+
+## Human approval gates
+<!-- Where a person must review, approve, reject, or supply missing context before the system writes externally or treats a document as approved. -->
+
+## Evaluation
+<!-- How quality will be measured. Include rubric dimensions, pass/fail checks, trace evidence, and examples of unacceptable output. -->
+
+## Failure modes
+<!-- What could go wrong if the system is followed too literally, over-automated, or used with weak evidence. Include mitigations. -->
+
+## Rollout
+<!-- How this operating model becomes the default. Include migration steps, owners, training, and when older templates or workflows are retired. -->
+
+## Open questions
+<!-- Questions that could change the operating model. Each should have an owner and decision date. -->
+
+## References
+<!-- Linked examples, prior PRDs, Meta PRDs, research, tickets, traces, or decisions. -->

package/templates/docs/one-pager.md

@@ -0,0 +1,24 @@
+# One-pager: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+
+<!-- Strict one-page constraint. If it does not fit, it is not a one-pager. Cut until it fits. -->
+
+## Problem
+<!-- One paragraph. What pain, for whom, at what scale. -->
+
+## Proposal
+<!-- One paragraph. What we will do, at a level a non-specialist can understand. -->
+
+## Why now
+<!-- One paragraph. What makes this the right moment — a trigger, a constraint, a window. -->
+
+## Success measure
+<!-- The single metric that tells us this worked. Numeric, time-bound. -->
+
+## Cost
+<!-- People, time, money. Rough order of magnitude. -->
+
+## Asks
+<!-- What you need from the reader to unblock this. Headcount, approval, a decision by a specific date. -->

package/templates/docs/prd-business.md

@@ -0,0 +1,61 @@
+# Business PRD: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | in-review | approved | shipped | deprecated
+
+<!--
+Use this for strategic bets, market positioning decisions, business model changes,
+partnership structures, pricing strategy, and make-vs-buy decisions.
+
+This is not a feature spec. It defines the bet, the market thesis, the alternatives
+rejected, and what would have to be true for this to work.
+
+Use prd.md for customer-facing product capabilities.
+Use prd-platform.md for internal platform and developer-facing capabilities.
+-->
+
+## The bet
+<!-- One or two sentences: what we are committing to and why now. This should be falsifiable. -->
+
+## Market thesis
+<!-- The one-paragraph view of market shape, buyer behavior, and where value accrues. Every decision in this document links back here or challenges it. -->
+
+## Problem and opportunity
+<!-- What is broken in the market or business today? What does the opportunity look like at full scale? State the pain and the size of the prize — with evidence. -->
+
+## Strategic goals
+<!-- What this decision achieves at the business level: position, revenue, defensibility, optionality. Tie to company objectives. -->
+
+## Alternatives rejected
+<!-- The other credible paths that were considered. For each: what it is, why it was rejected, and what would have to change to reconsider it. No strawmen. -->
+
+## What must be true
+<!-- The conditions that have to hold for this bet to pay off. Make them explicit so they can be monitored. -->
+
+## Competitive analysis
+<!-- For each relevant competitor: business model (unit economics, distribution, defensibility), not just feature surface. Avoid feature parity tables that ignore economics. -->
+
+## Make vs. buy vs. partner
+<!-- If applicable: the build/buy/partner tradeoffs with rationale. Include cost, control, speed, and strategic leverage. -->
+
+## Go-to-market implications
+<!-- Pricing, packaging, channels, positioning changes. What motion this requires from sales, marketing, or customer success. -->
+
+## Financial frame
+<!-- Revenue model, cost structure, expected unit economics. Include the range of outcomes, not just the upside case. -->
+
+## Kill criteria
+<!-- The leading indicator and the threshold at which this strategy is revisited or abandoned. Without this, bad bets survive longer than they should. -->
+
+## Risks
+<!-- Market, execution, regulatory, competitive, and technical risks. Rate each by likelihood and impact. State the mitigation or acceptance rationale. -->
+
+## Constraints
+<!-- Budget, timeline, team, regulatory, or partner dependencies that shape the scope of this decision. -->
+
+## Open questions
+<!-- Genuine unknowns. Each names an owner and a decision deadline. -->
+
+## References
+<!-- Market research, customer interviews, financial models, prior decisions, analyst reports, competitor filings. -->

package/templates/docs/prd-platform.md

@@ -0,0 +1,62 @@
+# Platform PRD: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | in-review | approved | shipped | deprecated
+
+<!--
+Use this for capabilities consumed by internal systems, developers, operators, or other
+services — not directly by end users. Covers APIs, SDKs, admin surfaces, data contracts,
+shared infrastructure, and operational tooling.
+
+Use prd.md instead for customer-facing product capabilities.
+Use meta-prd.md for requirements about the product operating system itself.
+
+Name the platform actor precisely: platform builder, application developer, security admin,
+operator. "Developer" is too broad.
+-->
+
+## Problem
+<!-- What is broken, missing, or blocking a platform actor or downstream system? One paragraph. State the operational or integration pain, not the solution. -->
+
+## Platform actors
+<!-- Who consumes this capability? Name roles precisely (app developer, ops engineer, data analyst, etc.). Include scale and current workaround. Cite evidence: tickets, incidents, support load. -->
+
+## Goals and non-goals
+<!-- Goals: what success looks like for the consumers. Non-goals: explicitly scoped out. -->
+
+## API and interface contract
+<!-- The surface being defined: endpoints, schemas, SDK methods, event payloads, config shapes, permission models. Number each contract item (C-1, C-2, …). -->
+
+## Functional requirements
+<!-- What the system must do. Number them (FR-1, FR-2, …). -->
+
+## Non-functional requirements
+<!-- Performance SLOs, reliability targets, security, compliance, scalability limits. Include numeric targets. -->
+
+## Backwards compatibility and versioning
+<!-- Is this a new contract or a change to an existing one? If a change: breaking vs. non-breaking, versioning strategy, and how existing consumers are supported. -->
+
+## Migration and rollout
+<!-- How consumers move to the new contract. Include migration steps, tooling, timeline, and who is responsible. Flag any coordination with downstream teams. -->
+
+## Operational requirements
+<!-- Observability (metrics, logs, traces), auditability, rate limits, failure modes, fallback behavior, support diagnostics, admin controls. These are product requirements, not afterthoughts. -->
+
+## Acceptance criteria
+<!-- Observable, falsifiable conditions a reviewer can check. Include integration and contract tests where relevant. -->
+
+## Success metrics
+<!-- How we know this worked: adoption, error rate, latency, support ticket reduction. Leading vs. lagging. -->
+
+## Consumer impact
+<!-- What changes for existing consumers. What breaks, what degrades, what stays the same. Link to migration guide if needed. -->
+
+## Dependencies
+<!-- Upstream services, data contracts, team availability, vendor timelines. -->
+
+## Open questions
+<!-- Genuine unknowns. Each question names an owner and a decision deadline. -->
+
+## References
+<!-- Linked designs, prior PRDs, ADRs, incidents, runbooks, tickets. -->

package/templates/docs/prd.md

@@ -0,0 +1,47 @@
+# PRD: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | in-review | approved | shipped | deprecated
+
+<!--
+Use this for a product capability, user workflow, or customer-facing requirement set.
+Use meta-prd.md instead when defining the requirements for a product system, agent,
+process, template, evaluation loop, or operating model.
+
+Write with a balance of short paragraphs, tables, and bullets. Bullets are for scans,
+not the whole document. Keep em dashes rare; prefer commas, periods, or parentheses.
+-->
+
+## Problem
+<!-- What is broken, missing, or blocking a user or business outcome? One paragraph. State the pain, not the solution. -->
+
+## Users
+<!-- Who experiences the problem? Segments, scale, current workaround. Cite evidence (tickets, interviews, data). -->
+
+## Goals and non-goals
+<!-- Goals: what success looks like. Non-goals: explicitly scoped out to keep the work bounded. -->
+
+## Functional requirements
+<!-- What the system must do. Number them (FR-1, FR-2, …) so they can be referenced in reviews and tests. -->
+
+## Non-functional requirements
+<!-- Performance, reliability, security, accessibility, compliance. Include numeric targets where possible. -->
+
+## Acceptance criteria
+<!-- Observable, falsifiable conditions a reviewer can check without asking the author. -->
+
+## Success metrics
+<!-- How we will know this worked in production. Leading vs. lagging. Avoid vanity metrics. -->
+
+## Constraints
+<!-- Budget, timeline, platform, team, legal, technical debt that shapes the solution. -->
+
+## Dependencies
+<!-- Teams, services, contracts, data sources, vendor timelines. -->
+
+## Open questions
+<!-- Genuine unknowns. Each question should name an owner and a decision deadline. -->
+
+## References
+<!-- Linked research, prior PRDs, ADRs, tickets, designs. -->

package/templates/docs/prfaq.md

@@ -0,0 +1,31 @@
+# PRFAQ: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Status**: draft | in-review | approved
+
+<!--
+Use for working-backwards product thinking. A PRFAQ can be generated from a PRD
+or directly from evidence, but it must not invent customer demand.
+-->
+
+## One-sentence summary
+<!-- One sentence for an executive reader. Name the audience and outcome. -->
+
+## Problem statement
+<!-- Two or three paragraphs grounded in evidence. Explain the customer problem, why now, and what is missing today. -->
+
+## Press release
+<!-- Write as if the capability has shipped. Focus on customer outcome, not implementation. -->
+
+## External FAQ
+<!-- Customer-facing questions and answers. Keep answers concrete and honest about limits. -->
+
+## Internal FAQ
+<!-- Questions from engineering, sales, support, security, finance, and leadership. Include unknowns as TBD with what would resolve them. -->
+
+## Evidence appendix
+<!-- Source links, customer quotes, related issues, research, and PRDs. -->
+
+## Review tracking
+<!-- Reviewer, function, decision, date, and required follow-up. -->

package/templates/docs/product-intelligence-report.md

@@ -0,0 +1,31 @@
+# Product Intelligence Report: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Owner**: {name}
+- **Scope**: {product-area | customer-segment | time-window}
+
+<!--
+Use for cross-source synthesis. This report should connect evidence to decisions
+without becoming a backlog dump.
+-->
+
+## Executive readout
+<!-- Two or three paragraphs. What changed, what matters, and what decision should follow. -->
+
+## Evidence base
+<!-- Summary of source types, coverage, recency, and known gaps. -->
+
+## Themes
+<!-- Each theme should include evidence strength, affected personas, representative sources, and counter-signal. -->
+
+## Customer asks
+<!-- Group asks by product area. Keep asks separate from committed requirements. -->
+
+## Product implications
+<!-- What this means for roadmap, positioning, reliability, platform, design, or research. -->
+
+## Recommended actions
+<!-- Action, owner, artifact to create or update, approval needed, target date. -->
+
+## Gaps and risks
+<!-- Missing evidence, biased source pools, unresolved questions, and likely false positives. -->

package/templates/docs/research-brief.md

@@ -0,0 +1,29 @@
+# Research Brief: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+- **Status**: in-progress | complete
+
+## Question
+<!-- The specific, falsifiable question this research is trying to answer. One sentence. -->
+
+## Method
+<!-- How the question was investigated. Sources consulted, queries run, experiments performed, people interviewed. Enough detail that another person could reproduce it. -->
+
+## Sources
+<!-- Primary sources, with links and access dates. Separate primary from secondary. Note where sources disagree. -->
+
+## Findings
+<!-- What the evidence says. Separate observation from inference. Label each finding with its confidence level. -->
+
+## Confidence
+<!-- Per finding: high / medium / low, and why. Name the biggest unknowns. -->
+
+## Implications
+<!-- What decisions this research enables or blocks. Who should act on it. -->
+
+## Open questions
+<!-- What this research did not resolve. What would be needed to answer each. -->
+
+## References
+<!-- Full citation list. -->

package/templates/docs/rfc-platform.md

@@ -0,0 +1,60 @@
+# Platform RFC: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+- **Status**: draft | in-review | accepted | rejected | superseded
+- **Change type**: breaking | non-breaking | additive
+- **Affects**: {API | SDK | schema | event | config | permission model | protocol}
+- **Supersedes**: {RFC title or N/A}
+
+<!--
+Use this when the proposal changes a contract consumed by other systems:
+APIs, SDKs, schemas, event payloads, permission models, config shapes, or protocols.
+
+Use rfc.md instead for proposals that do not touch external contracts.
+-->
+
+## Summary
+<!-- One paragraph. What contract is changing, in what direction, and why. -->
+
+## Motivation
+<!-- What problem or limitation in the current contract drives this change? Cite evidence: consumer pain points, incidents, performance data, support load. Explain why the current interface cannot simply be extended. -->
+
+## Breaking change declaration
+<!-- Be explicit: what is breaking, what is not. List every removed, renamed, or semantically changed interface element. Omitting a breaking change here is a contract violation. -->
+
+## Proposed contract
+<!-- The new interface in full. Schemas, endpoint signatures, payload shapes, permission rules, config fields. Be precise enough that a consumer can write against this spec without asking questions. -->
+
+## Backwards compatibility strategy
+<!-- How existing consumers are supported during transition. Options: versioning, dual-write, feature flags, shim layer, deprecation window. State which and why. -->
+
+## Migration guide
+<!-- Step-by-step: what a consumer must change, in what order, with examples. If migration tooling is provided, describe it. If migration is manual, estimate effort. -->
+
+## Versioning and deprecation
+<!-- Version scheme for this interface. Deprecation timeline for the old version: announcement date, sunset date, removal date. Include who owns communicating the deprecation to consumers. -->
+
+## Consumer impact analysis
+<!-- List known consumers. For each: what breaks, what changes, what stays compatible, estimated migration effort. Flag consumers that require coordinated migration. -->
+
+## Rollout plan
+<!-- How the new contract ships alongside the old one. Dual-version period, traffic migration, kill switch, removal gate. Include the observable signal that triggers each phase. -->
+
+## Operational requirements
+<!-- Observability, rate limits, error handling, fallback behavior, and admin controls required for the new contract to be supportable. -->
+
+## Tradeoffs and alternatives
+<!-- Other contract designs considered. For each: what it is, why it was not chosen. -->
+
+## Risks
+<!-- Compatibility gaps, consumer adoption risk, timing risk, coordination failure. For each: likelihood, impact, mitigation. -->
+
+## Verification
+<!-- How we confirm the migration succeeded and the old version can be safely removed. Metrics, tests, observable evidence. -->
+
+## Unresolved questions
+<!-- Genuine unknowns. Each names an owner and a decision deadline. -->
+
+## References
+<!-- Related ADRs, prior RFCs, API design guidelines, consumer runbooks, tickets. -->

package/templates/docs/rfc.md

@@ -0,0 +1,46 @@
+# RFC: {title}
+
+- **Date**: {YYYY-MM-DD}
+- **Author**: {name}
+- **Status**: draft | in-review | accepted | rejected | superseded
+- **Supersedes**: {RFC title or N/A}
+- **Superseded by**: {RFC title or N/A}
+
+<!--
+Use this for significant technical or architectural proposals that need structured
+review before implementation begins. An RFC is not an ADR (which records a decision
+already made) — it is the proposal that leads to one.
+
+Use rfc-platform.md instead when the proposal introduces breaking changes to a
+contract, API, schema, or protocol consumed by other systems.
+-->
+
+## Summary
+<!-- One paragraph. What is being proposed and why. Someone who reads only this should understand the intent. -->
+
+## Motivation
+<!-- What problem or limitation drives this proposal? Include evidence: incidents, performance data, support tickets, developer friction. Explain why the status quo is not acceptable. -->
+
+## Proposed design
+<!-- The concrete proposal. Enough detail for reviewers to evaluate feasibility and tradeoffs. Diagrams, code sketches, and data models are appropriate here. -->
+
+## Tradeoffs and alternatives
+<!-- The other credible designs considered. For each: what it is, why it was not chosen, and under what conditions it would be preferred. No strawmen. -->
+
+## Drawbacks
+<!-- What this proposal makes harder, slower, or more expensive. Include technical debt, operational complexity, and team burden. -->
+
+## Risks
+<!-- What could go wrong during implementation or in production. For each: likelihood, impact, and mitigation. -->
+
+## Rollout
+<!-- How this change ships. Phased rollout, feature flags, dark launch, migration path, deprecation timeline. -->
+
+## Verification
+<!-- How we confirm the proposal achieved its goals. Tests, metrics, observable evidence. -->
+
+## Unresolved questions
+<!-- Genuine unknowns that remain. Each names an owner and a decision deadline. These should be resolved before the RFC is accepted. -->
+
+## References
+<!-- Related ADRs, prior RFCs, design docs, tickets, research, external standards. -->