64 lines
2.4 KiB
Markdown
64 lines
2.4 KiB
Markdown
# Architecture Demand Intake
|
|
|
|
This directory is the unreviewed intake surface for proposed changes to the
|
|
Railiance framework architecture. It implements the InfoTechCanon distinction
|
|
between a `DemandSignal` and committed work:
|
|
|
|
- a file here records a request, opportunity, conflict, or observed scope
|
|
pressure;
|
|
- it is not a task and carries no implementation commitment;
|
|
- review compares it with `INTENT.md`, current `SCOPE.md`, existing ADRs, and
|
|
the purpose of the requesting consumer;
|
|
- only an accepted disposition may create or amend a workplan;
|
|
- resolved demand leaves this directory and moves to `history/` with its review
|
|
trail intact.
|
|
|
|
State Hub messages are coordination transport, not this directory's source of
|
|
truth. Capture a message here only when it presents genuine architecture demand
|
|
that needs review. Do not mirror the inbox wholesale.
|
|
|
|
## File convention
|
|
|
|
Pending demand uses `YYYY-MM-DD-NNN-<slug>.md` and this minimum shape:
|
|
|
|
```yaml
|
|
---
|
|
id: RMASTER-DEMAND-YYYY-MM-DD-NNN
|
|
type: demand-signal
|
|
status: unreviewed
|
|
received: "YYYY-MM-DD"
|
|
source: "operator | agent/repo | discovery"
|
|
consumer: "who needs the outcome"
|
|
---
|
|
```
|
|
|
|
Each record answers:
|
|
|
|
1. What is being requested or observed?
|
|
2. What consumer purpose would it serve?
|
|
3. How does it fit the producer intent?
|
|
4. Does it expose a current-scope defect, future-scope pressure, or work that
|
|
belongs elsewhere?
|
|
5. What evidence supports it?
|
|
|
|
## Review dispositions
|
|
|
|
- `accepted` — create or link the repo-local workplan, then archive the demand
|
|
record as `history/YYMMDD-demand-<slug>.md`.
|
|
- `routed` — name the owning repository and durable handoff evidence, then
|
|
archive the record.
|
|
- `deferred` — state the trigger or missing evidence; keep the record here only
|
|
while it remains genuinely unreviewed, otherwise archive it.
|
|
- `rejected` — record why it conflicts with intent, scope, or an accepted
|
|
decision, then archive it.
|
|
|
|
Review changes the demand record's status and adds reviewer, review date,
|
|
purpose fit, scope pressure, disposition rationale, and resulting work ID. Raw
|
|
demand must never move directly into task status without that trail.
|
|
|
|
## Worked example
|
|
|
|
The first completed intake is
|
|
[`history/260818-demand-canon-policy-alignment.md`](../history/260818-demand-canon-policy-alignment.md).
|
|
It records the operator request that became `RMASTER-WP-0024` and demonstrates
|
|
the full signal → review → workplan → history path.
|