77 lines
2.5 KiB
Markdown
77 lines
2.5 KiB
Markdown
# PR-06.6 - SPAWN/YIELD v1 or Claim Rescope
|
|
|
|
## Briefing
|
|
|
|
Os requisitos `G20-9.4.2` e `G20-9.4.3` estao `deferred` porque `SPAWN/YIELD` nao fazem parte do surface executavel v1 atual.
|
|
|
|
Esta PR fecha a pendencia por uma de duas trilhas exclusivas:
|
|
|
|
1. implementar `SPAWN/YIELD` em v1 com testes; ou
|
|
2. ajustar claim/perfil/spec para remover obrigacao deste escopo no v1 claimado.
|
|
|
|
## Motivation
|
|
|
|
### Dor atual que esta PR resolve
|
|
|
|
1. Nota JVM-grade fica penalizada por requisitos deferidos.
|
|
2. Claim de conformidade pode ficar ambiguo para auditoria externa.
|
|
3. Planejamento tecnico fica travado entre implementacao e re-scope.
|
|
|
|
## Target
|
|
|
|
Decisao implementada e test-backed para encerrar `deferred` com status claro.
|
|
|
|
## Dependencies
|
|
|
|
Prerequisitos variam por trilha:
|
|
|
|
1. Trilha A (implementar): depende de extensao do modelo `IRBackend/IRVM` para opcodes e verificacao.
|
|
2. Trilha B (re-scope): depende de alinhamento normativo com specs/decision.
|
|
|
|
## Scope
|
|
|
|
1. Trilha A:
|
|
- adicionar suporte `SPAWN/YIELD`,
|
|
- validar aridade e stack constraints,
|
|
- cobrir com testes positivos/negativos.
|
|
2. Trilha B:
|
|
- ajustar documentos para deixar explicito que nao e parte do profile v1 claimado,
|
|
- atualizar matriz e policy de claim.
|
|
|
|
## Non-Goals
|
|
|
|
1. Nao introduzir modelo completo de concorrencia/corrotina alem do minimo normativo.
|
|
2. Nao conflitar com autoridade de runtime/ISA.
|
|
|
|
## Method
|
|
|
|
### O que deve ser feito explicitamente
|
|
|
|
1. Escolher uma trilha oficial (A ou B) por decisao registrada.
|
|
2. Executar implementacao ou re-scope end-to-end (codigo + specs + matriz).
|
|
3. Garantir que `G20-9.4.2` e `G20-9.4.3` saiam de `deferred` para `pass` (A) ou status normativo explicitamente nao-aplicavel no claim v1 (B).
|
|
|
|
## Acceptance Criteria
|
|
|
|
1. Nao existe mais ambiguidade sobre `SPAWN/YIELD` no claim atual.
|
|
2. Matriz e specs refletem exatamente o comportamento implementado e claimado.
|
|
3. Gate de conformidade nao deixa regressao silenciosa nesses itens.
|
|
|
|
## Tests
|
|
|
|
1. Trilha A:
|
|
- testes de lowering/validator para `SPAWN` arg count e `YIELD` stack constraint.
|
|
2. Trilha B:
|
|
- testes de integridade documental/policy com checks de claim.
|
|
|
|
## Affected Documents
|
|
|
|
1. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
|
2. `docs/general/specs/22. Backend Spec-to-Test Conformance Matrix.md`
|
|
3. `docs/general/specs/17. Compatibility and Evolution Policy.md`
|
|
4. `docs/pbs/decisions/*` (decision de escopo, quando aplicavel)
|
|
|
|
## Open Questions
|
|
|
|
1. Qual trilha oficial deve ser adotada: implementacao v1 (A) ou re-scope de claim (B)?
|