Repository navigation
feat(ui): add portable appbar renderer and bounded status contract - #83
Merged
Merged
Conversation
landjunge
force-pushed
the
feat/e05-portable-appbar-20261020
branch
from
October 20, 2026 17:12
d016be9 to
f6b34de
Compare
landjunge
force-pushed
the
feat/e05-portable-appbar-20261020
branch
from
October 20, 2026 17:28
f6b34de to
968620f
Compare
landjunge
marked this pull request as ready for review
October 20, 2026 17:38
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Änderung
UI-01 erhält eine zentrale portable DOM/CSS-Grundlage1.0.0 mit kleinem festen Katalog und getrenntem Status-/Openvertrag. Keine TD-/AP-/KB-Mounts: KiraBridge bleibt die erste spätere Integration. Der Renderer fragt kein Netz ab, öffnet selbst keine App und hängt weder von React noch einer Pluginplattform ab.
Nur aktuelle Metadaten eines bereits authentisierenden Hostadapters mit erwarteter Peer-/Instanzbindung, Generation, Sequenz und begrenzter TTL dürfen bestätigen. AP4-Unlock verlangt zusätzlich den erlaubten passenden Nutzer/Tresor und eigene Frische. Kein Ring aus Start/PID/Transport; Bridgearbeit erhält keinen Puls. Öffnen hat getrennte Vorgangszuordnung, Deadline/Dedupe und keinen automatischen Retry oder Einfluss auf connected. Statusfrische und Öffnungsdeadline verwenden dieselbe konservative Messung mit monotoner Uhr und Wanduhr; beobachteter Rücksprung invalidiert den Vorgang dauerhaft. Auch nach Wanduhrfortschritt bei stehender monotoner Uhr bleibt ein verspäteter Öffnungserfolg unklar und gesperrt, bis der Host das Ziel prüft. Ein ungültiges Uhralter erfüllt niemals die600ms-Mindestwartezeit: Es sperrt auch nach sofortigem opened; erst explizite Hostprüfung startet eine volle neue600ms-Wartezeit. Tooltips bleiben bei Fokus, Text- und Fensteränderung horizontal sichtbar.
Assets, Farben und offene Nutzerfrage
Vorhandene freigegebene TD/AP4-PNGs bytegleich, portable lokale Kopien mit Version/Gitprovenienz/SHA256SUMS. Kein erfundenes KiraBridge-Icon. TD-Ringfarbe aus bestehender Marke. Für AP4 ist kein aktueller dokumentierter Ringtoken nachgewiesen: Katalogfarbe bleibt null/Status neutral, bis der vertrauenswürdige Host eine belegte benannte Farbe konfiguriert. Die Browserfixture nutzt ausdrücklich eine synthetische Testfarbe, keine Markenfreigabe.
Die24/32/40px-Maße sind nur der vorläufige Fixturestand. Daniels Größenfeedback ist noch keiner Oberfläche zugeordnet; weder Größenänderung auf Verdacht noch Nutzerabnahme. Bestehende Header-/Wordmark-/NP-Farben bleiben unberührt. Die separate belegte Vorschaukorrektur ist PR81.
Prüfung
Vertrag/Übernahme: docs/contracts/appbar-v1.md. Präzise Belege/Grenzen: docs/evidence/e05-portable-appbar-20261020/STATUS.md. Kleine begründete Formenwächterausnahme ausschließlich für den vom Nutzer verlangten runden Verbindungsring; NP-Bedienflächen bleiben eckig.
Offen: KiraBridge-Asset, AP4-Ringfarbtoken, Zuordnung der Icongrößenmeldung, KB-Ersteinbindung, echte abgesicherte Status-/Openadapter und danach Host-/Native-/Verbundabnahme. Unabhängige Source-/Browsernachprüfung durch den Koordinator steht aus. Kein Grok-Auftrag und keine Selbstintegration.
Abschließender Test-/Portabilitätsdelta: Resize wartet auf konkrete Tooltip-Bounds; alle gehashten Textdateien einschließlich bestehender networkpunkt.css sind LF-gebunden. Nach Rebase auf mainb32eef3 sind alle Runtime-/Bundlebytes d016-identisch. Frischer enger Resize-Lauf3/3 grün; isolierter autocrlf=true-Export bytegleich, kein Windows-Nativnachweis. Ein vorheriger Kombilauf wurde nach2pass wegen BrowserType.launch-Hänger kontrolliert abgebrochen; daraus wird keine grüne Vollsuite abgeleitet. Finaler unabhängiger Recheck/CI folgen.