134 lines
4.0 KiB
Markdown
134 lines
4.0 KiB
Markdown
# Diagnostics, Manifest Propagation, and Conformance Coverage Agenda
|
|
|
|
## Status
|
|
|
|
Open
|
|
|
|
## Parent Agenda
|
|
|
|
This agenda derives from:
|
|
|
|
- `19. Globals, Synthetic Module Init, and FRAME_RET Agenda`
|
|
|
|
Expected fixed inputs from previous stages:
|
|
|
|
- `19.1. PBS Globals Surface, Identity, and Module Boundaries Agenda`
|
|
- `19.2. PBS Lifecycle Markers, Program Init, and Frame Root Semantics Agenda`
|
|
- `19.3. Published Entrypoint, Synthetic Wrapper, and FRAME_RET Ownership Agenda`
|
|
- `19.4. Globals and Lifecycle Lowering to IRBackend/IRVM Agenda`
|
|
|
|
## Purpose
|
|
|
|
Consolidate the propagation layer of topic `19` after the architectural decisions are already fixed.
|
|
|
|
This agenda must close:
|
|
|
|
- the diagnostics surface;
|
|
- manifest-facing propagation details;
|
|
- fixture and conformance coverage;
|
|
- and the acceptance gates for declaring topic `19` ready to become a decision plus implementation plan.
|
|
|
|
## Domain Owner
|
|
|
|
`docs/compiler/pbs`
|
|
|
|
Este tema pertence ao domínio PBS, mas toca tanto specs normativas quanto critérios de teste e artefato publicado.
|
|
|
|
## Context
|
|
|
|
Depois que surface, lifecycle, published entrypoint e lowering estiverem fechados, ainda faltará consolidar:
|
|
|
|
- quais erros novos são obrigatórios;
|
|
- em que fase cada erro aparece;
|
|
- como o manifest final reflete a arquitetura escolhida;
|
|
- e que coverage mínima de fixtures e gates garante que a série 19 ficou estável.
|
|
|
|
Esta agenda é de consolidação. Ela não deve rediscutir a arquitetura central.
|
|
|
|
## Inputs Already Fixed Elsewhere
|
|
|
|
Os seguintes inputs devem ser tratados como fixos aqui:
|
|
|
|
- shape de globals vindo de `19.1`;
|
|
- lifecycle vindo de `19.2`;
|
|
- publication contract vindo de `19.3`;
|
|
- lowering mechanics vindo de `19.4`.
|
|
|
|
## Decisions To Produce
|
|
|
|
Esta agenda deve produzir direção suficiente para fechar:
|
|
|
|
1. catálogo mínimo de diagnósticos;
|
|
2. fase responsável por cada diagnóstico;
|
|
3. propagação final para manifest/specs;
|
|
4. fixture matrix mínima;
|
|
5. critérios de aceite para converter a série 19 em `decision` e depois `pull-request/plan`.
|
|
|
|
## Core Questions
|
|
|
|
1. Quais diagnósticos são obrigatórios para `declare global`, imports/reexports e ciclos?
|
|
2. Quais diagnósticos são obrigatórios para `[Init]` e `[Frame]`?
|
|
3. Quais erros pertencem a parser/AST, static semantics/linking, lowering, ou toolchain full pipeline?
|
|
4. Como o manifest final deve refletir entrypoint lógico e/ou físico escolhido em `19.3`?
|
|
5. Que fixtures mínimas precisam existir para globals, module init, boot failure, wrapper e `FRAME_RET`?
|
|
6. Em que ponto a configuração explícita antiga de entrypoint em `FrontendSpec` pode ser considerada removida?
|
|
7. Quais gates de conformance precisam ser atualizados para cobrir a série 19?
|
|
|
|
## Options
|
|
|
|
### Option A
|
|
|
|
Consolidar diagnostics e coverage somente depois que os quatro stages anteriores estiverem fechados, com fixture matrix explícita por fase.
|
|
|
|
### Option B
|
|
|
|
Começar fixtures e diagnostics cedo, mesmo com arquitetura ainda mudando.
|
|
|
|
## Tradeoffs
|
|
|
|
### Option A
|
|
|
|
- Prós:
|
|
- reduz retrabalho;
|
|
- evita congelar erro e coverage cedo demais;
|
|
- combina melhor com a disciplina de umbrella agenda.
|
|
- Contras:
|
|
- posterga parte da validação final.
|
|
|
|
### Option B
|
|
|
|
- Prós:
|
|
- feedback mais cedo.
|
|
- Contras:
|
|
- alto risco de churn e reabertura de artefatos;
|
|
- conflita com os locking rules da umbrella 19.
|
|
|
|
## Recommendation
|
|
|
|
Seguir com a **Option A**.
|
|
|
|
## Expected Spec Material
|
|
|
|
Se esta agenda fechar, a propagação esperada atinge pelo menos:
|
|
|
|
- `7. Cartridge Manifest and Runtime Capabilities Specification.md`
|
|
- `12. Diagnostics Specification.md`
|
|
- `13. Lowering IRBackend Specification.md`
|
|
- docs de conformance/fixtures relevantes
|
|
|
|
## Non-Goals
|
|
|
|
Esta agenda não deve:
|
|
|
|
1. redefinir semântica de globals;
|
|
2. redefinir lifecycle;
|
|
3. redefinir wrapper ou ownership de `FRAME_RET`;
|
|
4. redefinir shape de IR.
|
|
|
|
## Next Step
|
|
|
|
Depois do fechamento desta agenda, a linha `19` fica pronta para:
|
|
|
|
- virar uma `decision` consolidada em `docs/compiler/pbs/decisions`;
|
|
- e então ser decomposta em `pull-request/plan` de execução.
|