# 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.