prometeu-studio/docs/compiler/pbs/agendas/19.4. Globals and Lifecycle Lowering to IRBackend-IRVM Agenda.md

# Globals and Lifecycle Lowering to IRBackend/IRVM 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`

## Purpose

Define how the already-decided globals and lifecycle model are represented and lowered through the executable compiler pipeline.

This agenda must close:

- the representation boundary for globals;
- module init synthesis;
- boot guard materialization;
- wrapper lowering;
- and the executable path that preserves the chosen `FRAME_RET` ownership.

## Domain Owner

`docs/compiler/pbs`

Este tema pertence ao domínio PBS, mas encosta diretamente nas specs gerais de lowering e nas interfaces entre frontend e backend.

## Context

Depois que surface, lifecycle e publication contract estiverem fechados, ainda restará decidir:

- em que boundary globals passam a existir como entidade explícita;
- se `IRBackend` carrega globals diretamente ou só uma forma anterior;
- como module init sintético é representado;
- como o wrapper published entrypoint é emitido;
- como o guard one-shot de boot é materializado.

Esta agenda é mecânica/arquitetural. Ela não deve reabrir decisões de linguagem.

## Inputs Already Fixed Elsewhere

Os seguintes inputs devem ser tratados como fixos aqui:

- surface e identidade de globals vindas de `19.1`;
- lifecycle semântico vindo de `19.2`;
- owner do published entrypoint e de `FRAME_RET` vindo de `19.3`;
- `GET_GLOBAL` e `SET_GLOBAL` já existem na VM.

## Decisions To Produce

Esta agenda deve produzir direção suficiente para fechar:

1. se globals entram explicitamente no `IRBackend` ou apenas em lowering posterior;
2. como module init é sintetizado;
3. como o guard one-shot de boot é materializado;
4. como o wrapper é lowered;
5. como `FRAME_RET` é preservado no ponto correto;
6. quais contracts gerais de lowering precisam propagação.

## Core Questions

1. `IRBackend` deve ganhar representação explícita para globals?
2. Se não, qual é o boundary intermediário responsável por materializá-los antes de `IRVM`?
3. Module init sintético é emitido como callable próprio por módulo?
4. O boot guard é global oculto, local estático de wrapper, ou outra forma interna?
5. O wrapper published entrypoint é um callable sintético explícito no graph do frontend?
6. Como manter attribution e diagnostics úteis para código sintético?
7. Que mudanças mínimas precisam acontecer em specs gerais fora de `docs/compiler/pbs`?
8. O lowering deve introduzir uma classe explícita de funções sintéticas com ergonomia própria, em vez de emissão ad hoc?

## Options

### Option A

Dar representação explícita a globals e callables sintéticos já no boundary de `IRBackend`, preservando attribution e identidade suficientes para lowering posterior.

### Option B

Manter `IRBackend` sem globals explícitos e adiar essa materialização para um lowering mais baixo.

### Option C

Tratar globals como açúcar compilado diretamente para slots/ops sem entidade intermediária estável.

## Tradeoffs

### Option A

- Prós:
  - boundary mais explícito e testável;
  - menor inferência textual em lowers posteriores;
  - facilita explicar wrapper e init synthesis.
- Contras:
  - aumenta o contrato do `IRBackend`;
  - pode exigir propagação além do domínio PBS.

### Option B

- Prós:
  - preserva o boundary atual por mais tempo.
- Contras:
  - empurra complexidade para fases posteriores;
  - dificulta conformance do shape intermediário.

### Option C

- Prós:
  - menor aparente custo de modelagem.
- Contras:
  - fraco para teste, attribution e manutenção;
  - mistura lowering demais cedo.

## Recommendation

Seguir com a **Option A**, salvo impedimento forte de boundary cross-domain.

## Current Direction

Os pontos abaixo já podem ser tratados como direção fechada desta agenda, salvo objeção nova forte:

1. globals devem entrar explicitamente no `IRBackend`;
2. o pipeline não deve adiar globals para uma materialização implícita tardia abaixo desse boundary;
3. fragments de init por arquivo, init sintético por módulo, init de projeto e wrapper published entrypoint devem existir como callables sintéticos explícitos;
4. o boot guard deve ser materializado como um global oculto;
5. esse global oculto não pode ser referenciado nem alterado por userland;
6. o wrapper published entrypoint deve existir explicitamente no graph de lowering;
7. o lowering deve seguir direção direta para as operações de globals já suportadas em `IRVM`/VM, isto é, `GET_GLOBAL` e `SET_GLOBAL`;
8. attribution e diagnostics devem preservar separadamente:
   - origem em source userland,
   - e origem sintética gerada pelo compiler;
9. quando algum erro estrutural ou de lowering surgir em código sintetizado, a superfície sintética deve ser capaz de carregar attribution de volta ao código real que originou aquele trecho;
10. spans e diagnostics devem preferir apontar para código real de userland sempre que essa origem existir;
11. o frontend/lowering deve introduzir uma classe explícita de funções sintéticas com ergonomia própria;
12. a emissão dessas funções não deve ser ad hoc caso a caso.

## Synthetic Callable Direction

Esta agenda também fecha a seguinte direção arquitetural:

1. callables sintéticos não devem ser tratados como acidentes de emissão;
2. eles devem possuir classe/identidade própria no lowering;
3. essa classe deve cobrir pelo menos:
   - fragmentos de init por arquivo,
   - init sintético por módulo,
   - init de projeto,
   - wrapper físico publicado;
4. a ergonomia dessa classe própria deve facilitar:
   - ordenação,
   - attribution,
   - debug,
   - testes,
   - e futuras extensões de lifecycle sem reabrir o modelo básico.

Também fica fechada a seguinte exigência de diagnóstico:

1. a superfície sintética precisa carregar origem suficiente para remapear erros ao código real;
2. quando existir origem userland inequívoca, o diagnóstico deve preferir essa origem em vez de um span puramente sintético;
3. spans puramente sintéticos só devem aparecer quando não houver origem real defensável.

## Hidden Boot Guard Direction

O boot guard também fica com direção fechada nesta agenda:

1. ele deve existir como global oculto de programa;
2. ele pertence ao estado interno publicado pelo compiler;
3. userland não pode nomeá-lo, ler seu valor ou alterá-lo;
4. sua única função é garantir a semântica one-shot do bootstrap no wrapper físico.

## IRBackend Shape Direction

Esta agenda também fecha o seguinte shape estrutural mínimo para o `IRBackend`.

### 1. Backend Globals

O `IRBackend` deve carregar globals explicitamente como entidades estruturais, não apenas como efeitos implícitos no corpo de funções.

Direção mínima recomendada para cada global:

- `name`
- `ownerModuleId`
- `type`
- `slot`
- `visibility`
- `isHidden`
- `origin`

Isso deve cobrir:

- globals de userland;
- e globals ocultos do compiler, incluindo o boot guard.

### 2. Backend Callables

O `IRBackend` deve distinguir explicitamente:

- callables normais de userland;
- callables sintéticos gerados pelo compiler.

### 3. Synthetic Callable Kind

O conjunto mínimo de kinds sintéticos desta agenda deve cobrir:

- `FILE_INIT_FRAGMENT`
- `MODULE_INIT`
- `PROJECT_INIT`
- `PUBLISHED_FRAME_WRAPPER`

### 4. Synthetic Origin

Todo callable ou global sintético deve carregar metadados suficientes para attribution e remapeamento de diagnóstico.

Direção mínima recomendada:

- `derivedFromFile`
- `derivedFromModule`
- `derivedFromUserSymbol`
- `primarySpan`
- `fallbackSyntheticLabel`

### 5. Hidden Global Kind

O boot guard deve aparecer como global oculto com identidade estrutural explícita, não como convenção informal de nome.

Direção mínima recomendada:

- `BOOT_GUARD`

## Diagnostics and Conformance Direction

Esta agenda também fecha o seguinte conjunto mínimo de checks estruturais e evidências de conformance.

### Structural Diagnostics / Validation

1. `synthetic wrapper entrypoint missing`
   - quando o pipeline não conseguir publicar o wrapper exigido.
2. `published entrypoint is not function index 0`
   - quando o lowering violar o protocolo físico.
3. `hidden boot guard is missing`
   - quando a semântica one-shot exigir o guard e ele não existir.
4. `synthetic callable origin missing`
   - quando o lowering gerar callable sintético sem attribution suficiente para diagnóstico defensável.

### Conformance / Fixture Expectations

1. fixture com `declare global` + `[Init]` por arquivo + `[Init]` de projeto + `[Frame]`;
2. evidência de geração de:
   - file init fragment,
   - module init,
   - project init,
   - published wrapper,
   - hidden boot guard;
3. evidência de que o wrapper ocupa `func_id = 0`;
4. evidência de que `FRAME_RET` está no wrapper;
5. evidência de que erro em lowering sintético remapeia para span real quando houver origem de userland defensável.

## Spec and Learn Propagation Direction

Esta agenda também fecha a seguinte direção editorial:

1. specs de lowering devem explicar de forma normativa:
   - a classe de callables sintéticos,
   - o lifecycle de init no lowering,
   - o wrapper publicado,
   - o hidden boot guard,
   - e a relação desses artefatos com attribution e diagnostics;
2. `learn` deve explicar esse modelo de forma didática com exemplos de código source;
3. `learn` deve mostrar como:
   - `declare global`,
   - `[Init]` por arquivo,
   - `[Init]` de projeto,
   - e `[Frame]`
   se compõem até virar o wrapper físico publicado;
4. a explicação didática em `learn` deve privilegiar exemplos concretos de source e composição, não apenas descrição abstrata do pipeline.

## Expected Spec Material

Se esta agenda fechar, a propagação esperada atinge pelo menos:

- `13. Lowering IRBackend Specification.md`
- specs gerais de lowering/backend fora do domínio PBS, se necessário
- `12. Diagnostics Specification.md`

## Non-Goals

Esta agenda não deve:

1. redefinir surface syntax;
2. redefinir lifecycle;
3. redefinir manifest publication;
4. fechar catálogo final de fixtures.

## Next Step

Depois de fechar esta agenda, abrir ou aprofundar:

- `19.5. Diagnostics, Manifest Propagation, and Conformance Coverage Agenda`