106 lines
3.9 KiB
Markdown
106 lines
3.9 KiB
Markdown
---
|
|
id: PLN-0045
|
|
ticket: internal-viewport-270p
|
|
title: Specs and Docs Publication for 270p
|
|
status: review
|
|
created: 2026-04-27
|
|
completed:
|
|
tags: [specs, docs, runtime, viewport, resolution]
|
|
---
|
|
|
|
## Briefing
|
|
|
|
This plan executes the final mandatory slice of `DEC-0022`: publish the accepted `480x270` console contract in canonical specs and supporting documentation after runtime and host propagation are already in place.
|
|
|
|
This plan must run last. It exists to prevent public documentation from getting ahead of executable reality.
|
|
|
|
## Decisions de Origem
|
|
|
|
- `DEC-0022` - Internal Viewport 270p (480x270) as Canonical Runtime Contract
|
|
|
|
## Alvo
|
|
|
|
Update canonical published documentation so the repository describes Prometeu as a `480x270` console with matching framebuffer and touch coordinate semantics.
|
|
|
|
## Escopo
|
|
|
|
- Update runtime specs that explicitly publish `320x180`.
|
|
- Update any nearby prose that describes visual behavior in a way that now depends on the new baseline.
|
|
- Update related README/index material if it repeats the old resolution as canonical fact.
|
|
|
|
## Fora de Escopo
|
|
|
|
- Runtime or host code changes.
|
|
- Asset migration.
|
|
- Any broader narrative cleanup unrelated to the 270p contract.
|
|
|
|
## Plano de Execucao
|
|
|
|
### Step 1 - Update framebuffer and graphics specs
|
|
|
|
**What:**
|
|
Publish `480x270` as the canonical graphics/framebuffer resolution in the runtime graphics spec.
|
|
|
|
**How:**
|
|
Update the base-resolution and related descriptive sections so they state the new canonical resolution without ambiguity. Any prose that references `320x180` as a defining visual baseline must be revised to stay accurate.
|
|
|
|
**File(s):**
|
|
- `docs/specs/runtime/04-gfx-peripheral.md`
|
|
|
|
### Step 2 - Update touch coordinate contract
|
|
|
|
**What:**
|
|
Publish the new absolute touch domain that matches the 270p framebuffer.
|
|
|
|
**How:**
|
|
Update the touch spec so resolution, coordinate ranges, and any coordinate-space examples reflect `[0, 479] x [0, 269]`.
|
|
|
|
**File(s):**
|
|
- `docs/specs/runtime/07-touch-peripheral.md`
|
|
|
|
### Step 3 - Sweep remaining resolution references in runtime docs
|
|
|
|
**What:**
|
|
Remove remaining canonical `320x180` references from runtime docs and supporting material where they now contradict `DEC-0022`.
|
|
|
|
**How:**
|
|
Search runtime specs and adjacent docs for explicit resolution references and update only the ones that are part of the public console contract. Do not rewrite unrelated prose that merely mentions resolution in a different context unless it becomes incorrect after the migration.
|
|
|
|
**File(s):**
|
|
- `docs/specs/runtime/*.md`
|
|
- `docs/specs/runtime/README.md`
|
|
- any other directly affected docs under `docs/`
|
|
|
|
## Criterios de Aceite
|
|
|
|
- Canonical runtime docs publish `480x270` as the official internal resolution.
|
|
- Touch docs publish coordinate ranges consistent with `480x270`.
|
|
- No remaining public spec text describes `320x180` as the canonical console baseline.
|
|
- Documentation order reflects executable truth: runtime/host migration is already completed before docs close.
|
|
|
|
## Tests / Validacao
|
|
|
|
### Unit Tests
|
|
|
|
- No code unit tests are required for documentation-only changes.
|
|
|
|
### Integration Tests
|
|
|
|
- Re-run any repository validation or doc-linked checks that are already part of the normal workflow if available.
|
|
|
|
### Manual Verification
|
|
|
|
- Read the updated specs end-to-end for `gfx` and `touch` to confirm they agree with `DEC-0022`.
|
|
- Confirm no public-facing contradiction remains between docs and the implemented runtime baseline.
|
|
|
|
## Riscos
|
|
|
|
- Publishing docs before code would create a contract/execution mismatch; this is why this plan must remain last.
|
|
- Resolution references can hide in explanatory prose and examples, not only in obvious headings.
|
|
- Over-editing adjacent docs can accidentally turn a narrowly scoped publication task into a broad editorial rewrite.
|
|
|
|
## Dependencies
|
|
|
|
- `PLN-0043` MUST complete first.
|
|
- `PLN-0044` SHOULD complete first, and MUST complete first if any host-facing docs mention live desktop behavior.
|