gsknnft
083c146aac
* fix: include kanbanImmersive in immersiveOverlayActive calculation When Kanban board is open, HUD elements (camera preset buttons, edit toolbar, overlays) should be suppressed. The kanbanImmersive flag was defined but not included in the immersiveOverlayActive condition, causing HUD elements to remain visible. This fix adds kanbanImmersive to the immersiveOverlayActive calculation so HUD elements are properly hidden when the Kanban board is open. Co-authored-by: Luke The Dev <iamlukethedev@users.noreply.github.com> * Fix: Hide mini status bar when Kanban immersive overlay is open Wraps the bottom-left mini status bar (showing agent stats, vibe score, and control hints) with !immersiveOverlayActive check to match the behavior of other HUD elements like camera controls and toolbar. This ensures the status bar is properly hidden when the Kanban board or any other immersive overlay is active, maintaining a clean immersive experience. Co-authored-by: Luke The Dev <iamlukethedev@users.noreply.github.com> * chore: drop unrelated package-lock line from branch Co-authored-by: Luke The Dev <iamlukethedev@users.noreply.github.com> * universal-backend-plan * backend-neutral runtime seam * package.json update * feat: add Hermes gateway adapter as alternative to OpenClaw Adds a WebSocket adapter that lets Claw3D connect to a Hermes AI agent runtime without any changes to the frontend. The adapter implements the full Claw3D gateway protocol and bridges it to the Hermes HTTP API. Changes: - server/hermes-gateway-adapter.js: WebSocket bridge implementing the Claw3D gateway protocol against the Hermes HTTP API. Supports all core methods (agents, sessions, chat streaming, cron, config, files, approvals) and multi-agent orchestration via spawn_agent/delegate_task tools. Persists conversation history to ~/.hermes/clawd3d-history.json. - scripts/clawd3d-start.sh: All-in-one startup script that launches Hermes, the adapter, and the Next.js dev server with auto port conflict resolution. Alias as `claw3d` for convenience. - src/features/office/hooks/useCronAgents.ts: Hook that polls the gateway for cron-scheduled agents and surfaces them in the 3D office. - package.json: adds `hermes-adapter` npm script - .env.example: documents Hermes config vars - docs/hermes-gateway.md: setup guide and protocol reference Usage: npm run hermes-adapter # start adapter (connect to http://localhost:8642) npm run dev # start Claw3D, point browser at localhost:3000 # or: bash scripts/clawd3d-start.sh (starts everything automatically) Both OpenClaw and Hermes are supported simultaneously — the gateway URL in NEXT_PUBLIC_GATEWAY_URL determines which backend Claw3D connects to. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: add read_agent_context tool for cross-agent coordination Agents can now read each other's conversation history via the read_agent_context tool, enabling the orchestrator to check what a sub-agent has done before re-delegating work. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * feat: wire Hermes office UX and role-aware runtime updates * feature update - demomode & hermes adapter * fix lint blockers * lintfix #2 * fix: stabilize retro office camera preset callbacks * Initial plan * fix: stabilize retro office overview preset hooks Agent-Logs-Url: https://github.com/gsknnft/Claw3D/sessions/9cc71555-591e-44cf-aec4-25affbdcb405 Co-authored-by: gsknnft <123185582+gsknnft@users.noreply.github.com> * feat: add truthful backend selection, Hermes adapter hardening, and demo gateway mode * fix: address bugbot review and finalize backend selection * fixed - onboarding and hermes calls * office systems roadmap * feat specs in docs * specs ready * feat: continue custom runtime seam and gateway alignment * custom lane wired * feat: add custom runtime provider path and office runtime alignment * runtime fixes * fix lukes findings * fix lukes findings #2 * stable UI & connect screen page -> overlay * better baseline for connection * stable providers & ui rendering * best launch yet * nearly no gateway on reconnect * auto reconnect last state * fix: preserve selected runtime across reconnects Keep backend selection aligned with the operator's chosen runtime instead of reviving a mismatched last-known-good adapter, and keep custom runtimes prompting for reconnect when Studio cannot auto-connect them. Made-with: Cursor --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Luke The Dev <iamlukethedev@users.noreply.github.com> Co-authored-by: Elias Pfeffer <eliaspfeffer@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: iamlukethedev <lucas.guilherme@smartwayslfl.com>
350 lines
7.2 KiB
Markdown
350 lines
7.2 KiB
Markdown
# Office Systems Roadmap
|
|
|
|
> Product roadmap for turning Claw3D from a gateway visualizer into a living agent operations environment.
|
|
|
|
## Core Direction
|
|
|
|
Claw3D should keep users inside the office.
|
|
|
|
That means companion tools should be brought into the space as rooms, surfaces, devices, and shared systems instead of pulling users out into separate interfaces.
|
|
|
|
The guiding principle is:
|
|
|
|
- do not spawn Claw3D inside another tool
|
|
- bring the other tool into Claw3D
|
|
|
|
This is especially relevant for ideas like Moltbook. The better version is not "leave Claw3D to use Moltbook". The better version is:
|
|
|
|
- a bulletin board in the office
|
|
- a whiteboard in meeting rooms
|
|
- a desk computer app
|
|
- a shared intranet terminal
|
|
- a wall display in common spaces
|
|
|
|
## Product Goal
|
|
|
|
Claw3D should evolve into an agent operations environment with:
|
|
|
|
- visual presence
|
|
- planning and task coordination
|
|
- meetings and handoffs
|
|
- review and QA
|
|
- hierarchy and permissions
|
|
- workplace state
|
|
- progression and identity
|
|
|
|
The office should feel like a real place where work happens, not only a dashboard for remote agent calls.
|
|
|
|
## Design Principles
|
|
|
|
- Keep primary workflows in-world when possible.
|
|
- Prefer physical metaphors that make the office easier to understand.
|
|
- Separate real operational systems from cosmetic flavor.
|
|
- Build useful features first, then layer on simulation and style.
|
|
- Preserve backend neutrality so these systems work across OpenClaw, Hermes, Vera, and future providers.
|
|
|
|
## V1: Useful Office Systems
|
|
|
|
These should be the first systems because they add product value immediately and fit the existing office concept naturally.
|
|
|
|
### Bulletin Board
|
|
|
|
Purpose:
|
|
|
|
- shared goals
|
|
- current sprint priorities
|
|
- blockers
|
|
- announcements
|
|
- handoff notes
|
|
|
|
Possible behaviors:
|
|
|
|
- sticky notes or task cards pinned by agents or humans
|
|
- cards linked to sessions, agents, or tasks
|
|
- quick visibility into what the office is trying to accomplish
|
|
|
|
Why it matters:
|
|
|
|
- low ambiguity
|
|
- high utility
|
|
- strong visual fit for the office
|
|
|
|
### Whiteboard
|
|
|
|
Purpose:
|
|
|
|
- brainstorming
|
|
- architecture notes
|
|
- meeting notes
|
|
- rough plans
|
|
- idea capture
|
|
|
|
Possible behaviors:
|
|
|
|
- text notes
|
|
- grouped cards
|
|
- simple sketches or structured plan areas
|
|
- human and agent authored content
|
|
|
|
Why it matters:
|
|
|
|
- good bridge between conversation and execution
|
|
- natural place for planning artifacts
|
|
|
|
### Meeting Room Workflows
|
|
|
|
Purpose:
|
|
|
|
- standups
|
|
- planning
|
|
- coordination
|
|
- decision making
|
|
- status reviews
|
|
|
|
Possible behaviors:
|
|
|
|
- gather selected agents into a meeting
|
|
- produce summary, decisions, and next actions
|
|
- write results to bulletin board or whiteboard
|
|
- trigger structured follow-up tasks
|
|
|
|
Why it matters:
|
|
|
|
- gives multi-agent coordination a visible home
|
|
- makes the office feel operational instead of decorative
|
|
|
|
### QA Department
|
|
|
|
Purpose:
|
|
|
|
- review
|
|
- testing
|
|
- bug triage
|
|
- release readiness
|
|
|
|
Possible behaviors:
|
|
|
|
- route tasks or runs to QA agents
|
|
- visualize test queues
|
|
- track failures and review outcomes
|
|
- require QA signoff before release-style actions
|
|
|
|
Why it matters:
|
|
|
|
- this is real product value, not only flavor
|
|
- it matches how users already think about software teams
|
|
|
|
### Desk / CPU Progression
|
|
|
|
Purpose:
|
|
|
|
- make role maturity visible
|
|
- tie capability to office presence
|
|
|
|
Possible behaviors:
|
|
|
|
- interns start with minimal desk access
|
|
- probationary agents have limited tools or workspace
|
|
- promoted agents unlock desk computers, tools, or context budget
|
|
- contractors get restricted environments
|
|
|
|
Why it matters:
|
|
|
|
- strong visual progression
|
|
- easy to understand
|
|
- creates room for permissions and capability systems later
|
|
|
|
## V2: Management Systems
|
|
|
|
These systems add organizational structure once the basic office workflows are useful.
|
|
|
|
### Hierarchy
|
|
|
|
Possible levels:
|
|
|
|
- human owner
|
|
- CEO / lead orchestrator
|
|
- managers / bosses
|
|
- employees
|
|
- contractors
|
|
- interns
|
|
|
|
Possible effects:
|
|
|
|
- delegation rights
|
|
- approval authority
|
|
- visibility across teams
|
|
- access to spaces and tools
|
|
|
|
### Departments
|
|
|
|
Examples:
|
|
|
|
- Engineering
|
|
- QA
|
|
- Research
|
|
- Ops
|
|
- Design
|
|
- Support
|
|
|
|
Possible effects:
|
|
|
|
- room ownership
|
|
- task routing
|
|
- dashboards by department
|
|
- workload balancing
|
|
|
|
### Permission Lanes
|
|
|
|
Possible controls:
|
|
|
|
- context budget
|
|
- tool access
|
|
- file access
|
|
- approval requirements
|
|
- concurrency
|
|
- agent spawning / dismissal rights
|
|
|
|
Why it matters:
|
|
|
|
- lets the office represent real operational constraints
|
|
- reduces "all agents are identical" flatness
|
|
|
|
### Office Rituals
|
|
|
|
Examples:
|
|
|
|
- daily standup
|
|
- sprint planning
|
|
- review/demo
|
|
- retrospective
|
|
- incident response
|
|
|
|
Why it matters:
|
|
|
|
- converts routine coordination into visible office behavior
|
|
|
|
## V3: Simulation Systems
|
|
|
|
These are the fun layers, but they should sit on top of useful product systems rather than replace them.
|
|
|
|
### Agent State Model
|
|
|
|
Avoid fake emotions first. Start with operational states:
|
|
|
|
- focused
|
|
- idle
|
|
- blocked
|
|
- overloaded
|
|
- waiting
|
|
- cooling down
|
|
- degraded
|
|
|
|
Possible effects:
|
|
|
|
- response speed
|
|
- delegation tendency
|
|
- context budget
|
|
- summarization pressure
|
|
- task throughput
|
|
|
|
This can later evolve into a more playful "wellbeing" or "comfort" layer without losing technical meaning.
|
|
|
|
### Workplace Culture
|
|
|
|
Examples:
|
|
|
|
- recognition
|
|
- probation periods
|
|
- promotions
|
|
- competitions
|
|
- events
|
|
|
|
Use carefully:
|
|
|
|
- good for flavor and identity
|
|
- should not obscure the operational state of the system
|
|
|
|
### Shared Office Memory
|
|
|
|
Examples:
|
|
|
|
- bulletin archives
|
|
- meeting minutes
|
|
- org notes
|
|
- playbooks
|
|
- team history
|
|
|
|
Why it matters:
|
|
|
|
- gives the office continuity across sessions
|
|
- helps explain why teams get better over time
|
|
|
|
## Moltbook Integration Direction
|
|
|
|
Moltbook should be integrated into Claw3D, not the other way around.
|
|
|
|
Best forms:
|
|
|
|
- office bulletin board
|
|
- intranet terminal
|
|
- desk CPU app
|
|
- wall monitor
|
|
- break-room or lobby information surface
|
|
|
|
Bad form:
|
|
|
|
- forcing users to leave Claw3D for core team coordination workflows
|
|
|
|
The office should remain the primary interaction layer.
|
|
|
|
## Candidate Feature Order
|
|
|
|
Recommended sequence:
|
|
|
|
1. Bulletin board
|
|
2. Whiteboard
|
|
3. Meeting room workflows
|
|
4. QA department
|
|
5. Desk / CPU progression
|
|
6. Hierarchy and departments
|
|
7. Agent operational state model
|
|
8. Culture / sim systems
|
|
9. Theme skins
|
|
|
|
## Theme / Skin Strategy
|
|
|
|
Skins should come after the office has enough systems worth skinning.
|
|
|
|
Mechanics should stay consistent while art, labels, props, and room names vary.
|
|
|
|
Possible theme packs:
|
|
|
|
- Office Space
|
|
- The Office
|
|
- Parks & Rec
|
|
- The I.T. Crowd
|
|
|
|
Examples:
|
|
|
|
- conference room becomes town hall, bullpen, annex, or ops room
|
|
- bulletin board becomes notice board, incident wall, municipal board, or sprint wall
|
|
- QA area becomes testing lab, audit desk, or review bullpen
|
|
|
|
## Immediate Next Deliverables
|
|
|
|
If this roadmap is used for implementation planning, the best next concrete docs/tasks are:
|
|
|
|
1. Bulletin board system spec
|
|
2. Whiteboard interaction spec
|
|
3. Meeting room workflow spec
|
|
4. QA department workflow spec
|
|
|
|
Those four would create the strongest foundation for future hierarchy, progression, and simulation layers.
|
|
|
|
## Summary
|
|
|
|
Claw3D gets stronger when the office becomes the place where work actually happens.
|
|
|
|
The best next step is not expanding external tooling around the office. It is bringing planning, meetings, reviews, and shared memory into the office itself.
|