Advance app runtime ownership and modernization docs

This commit is contained in:
2026-06-16 06:35:59 +02:00
parent c3d757f4a4
commit a76560e3df
24 changed files with 6675 additions and 9009 deletions

View File

@@ -1,7 +1,7 @@
# PanoPainter Capability Map
Status: live
Last updated: 2026-06-05
Last updated: 2026-06-16
This map is the preservation checklist for the modernization. When a component
is extracted, update the relevant rows with the owning component, test label,
@@ -59,6 +59,7 @@ and validation command.
| Yoga layout | `Node` | `pp_ui_core` | Deterministic geometry fixtures |
| Generic controls | `NodeButton`, sliders, text, images | `pp_ui_core` | Event dispatch, layout, ownership-handle, callback-disconnect, and destroy-during-callback tests |
| PanoPainter panels/dialogs | `NodePanel*`, `NodeDialog*` | `pp_panopainter_ui`, `pp_ui_core` | UI automation scripts, command-dispatch view models, pure overlay lifetime tests, retained overlay-adapter build coverage, retained popup/dialog lifetime tests |
| UI ownership and thread affinity | `Node`, `LayoutManager`, `App` UI queue, retained callbacks | `pp_ui_core`, app runtime service, `pp_panopainter_ui` | Checked-handle dispatch, scoped callback disconnect, destroy-during-callback, close-during-dispatch, and UI-thread post/drain/shutdown coverage |
| Canvas viewport UI | `NodeCanvas` | `pp_panopainter_ui`, `pp_paint_renderer` | Input-to-command automation |
| Settings UI | `Settings`, `NodeSettings` | `pp_assets`, `pp_panopainter_ui` | Round-trip settings |
@@ -67,6 +68,7 @@ and validation command.
| Capability | Current Area | Target Owner | Required Tests |
| --- | --- | --- | --- |
| Mouse/keyboard/touch/gestures/cursor | `App`, platform entrypoints | `pp_app_core`, `pp_platform_api`, `pp_platform_*`, app | Cursor visibility decision tests, platform service dispatch tests, synthetic event playback |
| Render/UI task dispatch and worker shutdown | `App`, `Canvas`, retained worker threads, platform entrypoints | app runtime service, `pp_foundation`, `pp_platform_*` | Render/UI queue order, same-thread dispatch, cancellation, shutdown drain, and no-detached-worker ownership coverage |
| Wacom pressure | `WacomTablet` | `pp_platform_windows` | Adapter smoke with fallback |
| Clipboard/file picker/share/display | `App` platform methods | `pp_app_core`, `pp_platform_api`, `pp_platform_*` | Clipboard read/write, share saved-path, picked-path, and display-file decision tests, platform service display/share/picker dispatch tests, platform smoke or mocked service |
| Virtual keyboard | `App`, platform entrypoints | `pp_app_core`, `pp_platform_api`, `pp_platform_*` | Keyboard visibility decision tests, platform service dispatch tests, platform smoke |

View File

@@ -335,6 +335,10 @@ agent or engineer to remove them without reconstructing context from chat.
routes the stroke preset/brush/dual-brush/pattern popup open-close flow through
checked overlay handles and explicit partial-open cleanup; migration is still
pending in remaining panel families.
- 2026-06-16: `DEBT-0063` was narrowed again. `src/node_panel_stroke.cpp` now
routes stroke popup close/reset through a shared overlay helper, and
`src/node_popup_menu.cpp` now keeps the popup alive through selection dispatch
with scoped ownership instead of raw `this` callbacks.
- 2026-06-14: `DEBT-0063` was narrowed again. `src/node_panel_brush.cpp` now
routes brush popup-menu open-close flow through checked overlay handles and
handle-based close on selection.

View File

@@ -1,7 +1,7 @@
# Modernization Coordinator Workflow
Status: live
Last updated: 2026-06-14
Last updated: 2026-06-16
Use this workflow when the user explicitly asks for subagents, delegation, a
coordinator, or parallel agent work. Do not spawn subagents just because a task
@@ -16,10 +16,16 @@ layer.
- Save main-thread tokens by keeping implementation and focused lookup out of
the coordinator context.
- Treat thread compaction as wasted budget. Prefer small active context,
committed resume state, and fresh follow-on threads over carrying long stale
history.
- Keep each implementation slice measurable, validated, committed, and pushed.
- Avoid merge conflicts by giving every worker a disjoint task and file scope.
- Keep workers stateless between tasks: when a worker finishes, integrate or
reject the result, then clear that worker context before the next assignment.
- Do not leave workers idle. Either give a worker another coherent follow-on
task while its context is still useful, or close it promptly.
- Reuse worker context only for closely related follow-on tasks in the same
local area; otherwise close the worker and start a fresh one with a new
minimal packet.
- Keep prompts dense with the exact project/task context workers need so they do
not spend tokens re-reading repo docs or re-parsing broad areas.
- Keep communication terse: no fillers, no cheerleading, no narrative padding.
@@ -40,7 +46,8 @@ The coordinator is the main agent in the user thread. The coordinator owns:
- running final validation
- updating docs/debt/tasks
- committing and pushing the verified slice
- resetting worker context after each completed or rejected task
- either assigning coherent follow-on work to an active worker or closing that
worker once its useful context window is over
The coordinator should keep local work minimal. It may do a quick blocking
check before delegation, such as reading task rows, checking git status, or
@@ -49,13 +56,16 @@ code or test work, delegate it directly to a worker whenever the scope can be
made clear.
The coordinator must front-load context. Workers should not be told to "read
the roadmap" or "inspect the repo" unless that is the task. The coordinator is
responsible for extracting and passing:
the roadmap", "read AGENTS.md", or "inspect the repo" unless that is the task.
The coordinator is responsible for extracting and passing:
- task ids and done checks
- debt ids and removal conditions that matter
- exact write scope and allowed read scope
- required validation commands
- the specific build/test preset or target names the worker may need
- the exact code-exploration tools to use for the slice, such as `rg` or the
compiler-aware `clangd_nav.py` helper
- relevant file paths, code references, and current behavior notes
- any repo rules or user constraints that materially affect the task
@@ -68,6 +78,11 @@ Workers do not own repo discovery. They start from the coordinator-provided
context packet and stay inside the assigned scope unless they hit a blocker that
requires a narrow follow-up question.
Workers may be kept alive for more than one assignment only when the next task
is coherent with the current one: same subsystem, overlapping read scope,
similar validation path, and no avoidable context rebuild. Do not keep workers
alive just because a slot is available.
Every worker and explorer must be told:
- this repository may have other agents working in parallel
@@ -80,13 +95,13 @@ Every worker and explorer must be told:
| Work Type | Model | Reasoning Effort | Use |
| --- | --- | --- | --- |
| Coordinator orchestration and integration | inherited main-thread model or `gpt-5.4-mini` | `low` or `medium` | Scope selection, task routing, conflict checks, validation, docs/debt updates, commits, pushes. |
| Direct worker coding task | `gpt-5.3-codex-spark` | `medium` | Bounded implementation in known files with coordinator-supplied context. |
| Direct worker lookup or inventory | `gpt-5.3-codex-spark` | `low` or `medium` | `rg` inventory, file ownership map, simple grep-based answers. |
| Mechanical docs cleanup | `gpt-5.3-codex-spark` | `low` | Formatting, table updates, command normalization. |
| Coordinator orchestration and integration | `gpt-5.4` | `low` or `medium` | Scope selection, task routing, conflict checks, validation, docs/debt updates, commits, pushes, and worker packet preparation. |
| Direct worker coding task | `gpt-5.4-mini` | `medium` | Bounded implementation in known files with coordinator-supplied context. |
| Direct worker lookup or inventory | `gpt-5.4-mini` | `low` or `medium` | `rg` inventory, file ownership map, simple grep-based answers. |
| Mechanical docs cleanup | `gpt-5.4-mini` | `low` | Formatting, table updates, command normalization. |
| Coordinator-only escalation | inherited higher model only when explicitly justified | inherited | Resolve architecture ambiguity, conflict integration, or task decomposition failures without adding a captain layer. |
Workers default to `gpt-5.3-codex-spark`. If a task looks too broad or risky
Workers default to `gpt-5.4-mini`. If a task looks too broad or risky
for that model, the coordinator should decompose it further or keep the narrow
integration step locally instead of inserting an extra management tier.
@@ -96,33 +111,46 @@ integration step locally instead of inserting an extra management tier.
ids, validation commands, and only the necessary excerpts.
- Use `fork_context=true` only when prior conversation details are essential and
not already captured in the worker prompt.
- Do not let the coordinator thread drift toward compaction. Once a verified
slice is committed and pushed, prefer a fresh thread for the next slice if
the remaining context is no longer tight.
- Do not paste large logs into prompts. Point workers at log paths and ask for
the smallest relevant excerpt.
- Do not ask workers to broadly read `AGENTS.md`, the roadmap, or the debt log.
Summarize the exact rules and rows they need.
- Do not ask workers to broadly read `AGENTS.md`, the roadmap, the debt log, or
other repo-wide docs. Summarize the exact rules and rows they need.
- Default worker context to a minimal operating packet: task id, assigned file
scope, build command, test command, and code-exploration command hints.
- Keep worker prompts compact but complete. Shorter is good only if it still
removes the need for worker-side repo rediscovery.
- Ask for compact final reports: changed files, result, validation, blockers,
next recommendation.
- Close completed workers after their results are integrated or rejected.
- Keep active workers busy with another coherent task when that is cheaper than
restarting context; otherwise close them immediately after integration.
- Close workers that are done, blocked, or no longer have a strong context
advantage so they do not accumulate and saturate worker slots.
- Prefer the smallest number of concurrent workers that keeps disjoint work
moving.
- Use rolling integration: wait for whichever worker finishes first, process the
result, then launch the next disjoint worker with a fresh context window.
result, then either reuse that worker for the next coherent slice or close it
before launching a fresh worker for unrelated work.
- Prefer committed repo state over chat history as the handoff mechanism between
slices so worker and coordinator prompts stay short.
## Delegation Flow
1. Coordinator picks one or more `Ready` tasks from
`docs/modernization/tasks.md` with disjoint write scopes.
2. Coordinator splits each task into direct worker-sized units.
2. Coordinator splits each task into direct worker-sized units, grouping
coherent follow-on work when one worker can finish it efficiently without
broadening scope.
3. Coordinator prepares a context packet for each worker with the exact task
requirements, file scope, validation commands, and relevant project details.
4. Coordinator assigns the task directly to a `gpt-5.3-codex-spark` worker or
4. Coordinator assigns the task directly to a `gpt-5.4-mini` worker or
explorer.
5. Worker returns changed files, validation, blockers, and any narrow
integration notes.
6. Coordinator reviews for scope conflicts, integrates the result, and clears
that worker context before assigning the next task.
6. Coordinator reviews for scope conflicts, integrates the result, and decides
whether to give that same worker another coherent task or close it.
7. Coordinator runs the listed validation command or the quiet checkpoint
wrapper for each integrated slice.
8. Coordinator updates `tasks.md`, `debt.md`, and `roadmap.md` if task state or
@@ -132,7 +160,7 @@ integration step locally instead of inserting an extra management tier.
## Coordinator Prompt Template For A Worker
```text
You are a `gpt-5.3-codex-spark` worker on PanoPainter. Other agents may be
You are a `gpt-5.4-mini` worker on PanoPainter. Other agents may be
editing nearby files; do not revert unrelated changes.
Task source: docs/modernization/tasks.md task(s) <TASK-ID-LIST>.
@@ -142,15 +170,24 @@ Debt ids: <DEBT-LIST>.
Write scope: <FILES/DIRS ONLY>.
Read scope: <FILES/DIRS>.
Validation: <COMMANDS>.
Code exploration: <RG OR CLANGD_NAV COMMANDS TO USE>.
Repo constraints you must follow:
- <ONLY THE RELEVANT RULES>
Current context you should rely on instead of broad repo/doc review:
Minimal context you should rely on instead of broad repo/doc review:
- <CURRENT BEHAVIOR NOTE>
- <RELEVANT FILE OR SYMBOL NOTE>
- <WHY THIS SLICE IS SAFE / WHAT MUST NOT CHANGE>
Do not read repo-wide docs unless this task explicitly requires it. Use only
the supplied context, the listed file scope, and the build/test/code-exploration
commands above.
If the coordinator gives you a second task, accept it only when it is coherent
with the current scope and does not require broad repo rediscovery. Otherwise
say that a fresh worker should be used.
Make the smallest behavior-preserving change that satisfies the done checks.
Do not spend tokens on broad document review or inventory outside the assigned
scope unless the task explicitly requires it. If the task is larger than
@@ -187,6 +224,11 @@ Return only:
- Focused validation for the task passed or the failure is documented.
- `docs/modernization/debt.md` changed when debt was narrowed or closed.
- `docs/modernization/tasks.md` score changed only for `Done` tasks.
- Each worker result was integrated before that worker context was reused.
- Each worker result was integrated before that worker was reused.
- Reused workers only handled coherent follow-on tasks with a real context
advantage.
- Done or blocked workers were closed instead of being left idle.
- The coordinator did not carry unnecessary stale history when a fresh thread
would have been cheaper than compaction.
- The commit contains one coherent slice.
- The branch was pushed.

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff