What task are you trying to do?
Clean up PawWork-owned frontend hook names that still use the old opencode-* namespace, starting with desktop shell and titlebar DOM hooks. This is developer-facing hygiene: future UI work and E2E tests should be easier to grep and should not confuse PawWork-owned app shell code with upstream OpenCode compatibility surfaces.
Target date: 2026-05-03.
Which area would this change affect?
UI or design system
What do you do today?
Some PawWork frontend shell hooks still use opencode names, for example:
#opencode-titlebar-left#opencode-titlebar-center#opencode-titlebar-right- related E2E selectors in
packages/app/e2e/selectors.ts
This makes the code harder for humans and agents to read because opencode can mean either PawWork-owned legacy naming or true upstream/runtime compatibility.
What would a good result look like?
PawWork-owned frontend-only hooks use pawwork-* names, while true compatibility surfaces keep their existing names. The first pass should be a small, low-risk rename focused on app shell/titlebar DOM hooks and tests.
What would count as done?
- Rename PawWork-owned titlebar DOM hook IDs from
opencode-titlebar-* to pawwork-titlebar-*.
- Update app code that mounts portals into those titlebar slots.
- Update E2E selectors and shell-frame contract tests.
- Verify the titlebar and settings title still render correctly.
- Run the relevant app typecheck and titlebar/shell-frame tests.
What should stay out of scope?
- Do not rename
@opencode-ai/* package imports.
- Do not rename
virtual:opencode-server.
- Do not rename
OPENCODE_* env vars.
- Do not rename
opencode:// protocol links.
- Do not rename provider IDs such as
opencode or opencode-go.
- Do not change localStorage or theme persistence keys in this pass.
- Do not do a broad repository-wide string replacement.
Which audience does this matter to most?
Global users
Extra context
This came up while reviewing PR #360. The intent is to keep new or actively modified frontend code agent-readable: focused, easy to grep, and clear about PawWork-owned surfaces versus upstream compatibility surfaces.
What task are you trying to do?
Clean up PawWork-owned frontend hook names that still use the old
opencode-*namespace, starting with desktop shell and titlebar DOM hooks. This is developer-facing hygiene: future UI work and E2E tests should be easier to grep and should not confuse PawWork-owned app shell code with upstream OpenCode compatibility surfaces.Target date: 2026-05-03.
Which area would this change affect?
UI or design system
What do you do today?
Some PawWork frontend shell hooks still use
opencodenames, for example:#opencode-titlebar-left#opencode-titlebar-center#opencode-titlebar-rightpackages/app/e2e/selectors.tsThis makes the code harder for humans and agents to read because
opencodecan mean either PawWork-owned legacy naming or true upstream/runtime compatibility.What would a good result look like?
PawWork-owned frontend-only hooks use
pawwork-*names, while true compatibility surfaces keep their existing names. The first pass should be a small, low-risk rename focused on app shell/titlebar DOM hooks and tests.What would count as done?
opencode-titlebar-*topawwork-titlebar-*.What should stay out of scope?
@opencode-ai/*package imports.virtual:opencode-server.OPENCODE_*env vars.opencode://protocol links.opencodeoropencode-go.Which audience does this matter to most?
Global users
Extra context
This came up while reviewing PR #360. The intent is to keep new or actively modified frontend code agent-readable: focused, easy to grep, and clear about PawWork-owned surfaces versus upstream compatibility surfaces.