Pulse

• What Pulse enables
  • Proprietary Project Management System (Pulse PM)
    • Primary app surface
      • Pulse PM is the live work surface.
      • Pulse PM manages tasks, modules, sprints, users, and workspace state.
      • Pulse PM is designed to become a reusable PM utility for multiple future projects, not just one app.
    • Built from
      • Pulse PM uses a Next.js and React web app surface.
      • Pulse PM includes an admin surface for instance and operator controls.
      • Pulse PM uses a Python and Django API plus authentication backend.
      • Pulse PM uses a containerized app, API, and proxy deployment model.
      • Pulse PM depends on PostgreSQL, Redis, RabbitMQ, uploads storage, and internal MinIO.
    • Runs on
      • Pulse PM runs on the Mac Mini host.
      • Pulse PM runs in Docker-based Development and Private Shared Production lanes.
      • Pulse PM is reachable on the private network through the Ubiquity Private Network.
    • Current environment model
      • Local Pulse PM is the Development environment.
      • Pulse PM Private Shared is the Production environment.
      • Production owns live data authority.
  • OpenClaw Agents
    • Sven, the main agent
      • Sven speaks with Simon in chat.
      • Sven reads docs, memory, prompts, and runtime context.
      • Sven coordinates tools, coding work, research, and bounded actions.
      • Sven is the main agent layer that talks with Simon and coordinates project execution.
    • Otto and other subagents
      • Otto and other subagents handle focused lookup, analysis, implementation, and verification work.
      • Otto and other subagents can inspect code, docs, and project state in fresh sessions.
      • Otto and other subagents report results back to Sven for synthesis and next actions.
      • Otto is the named subagent identity for delegated work in this operating model.
    • Task operations
      • The agents look up tasks, modules, and sprint state through PMOS.
      • The agents write back bounded planning updates through PMOS.
      • The agents keep project routing explicit instead of guessed.
  • Development to Production work loop
    • Work is done locally in Development first.
    • Behavior is validated before promotion.
    • Git is used as a code-state boundary, not a restore boundary.
    • Bounded changes are promoted into Private Shared Production.
    • Production proof is required after deploy.
  • Customized operating system
    • OpenClaw runtime is part of the Pulse operating system.
    • PMOS bridge behavior and operator rules are part of the Pulse operating system.
    • Docs, prompts, runbooks, and memory are part of the Pulse operating system.
    • Systems Check and operator-truth surfaces are part of the Pulse operating system.
• Human + operator intent
  • Simon
    • Simon decides what work matters.
    • Simon chooses tradeoffs and approves risky actions.
    • Simon uses Pulse to plan, execute, validate, and promote work.
  • Operator expectations
    • The work should move one narrow change at a time.
    • Progress updates should say what changed, the expected effect, the risk, and what is still pending.
    • Outcomes should be classified as improvement, neutral, or regression.
    • Visible regressions should be reverted quickly.
• OpenClaw control layer
  • Main runtime
    • Sven runs in the OpenClaw workspace on the Mac Mini.
    • Sven uses local docs first for OpenClaw behavior and architecture.
    • Sven can inspect files, run tools, orchestrate work, and use terminal access on the Mac Mini.
    • The OpenClaw runtime includes tool routing, memory retrieval, messaging, browser automation, and session orchestration.
  • Subagents
    • Subagents use fresh child sessions for longer or more complex work.
    • Subagents are useful for isolated analysis or implementation passes.
    • Subagents are still coordinated by the main assistant.
  • Memory + retrieval
    • Markdown memory is the source of truth.
    • QMD is retrieval and indexing only.
    • Session continuity depends on files, not hidden memory.
  • Prompts, rules, and procedures
    • Startup grounding files define the initial operating context.
    • Backup, bounded, restore, and promotion prompts define the execution runbooks.
    • Operator guidance lives across OpenClaw and product docs.
  • Systems Check / operator truth
    • Ops Check is a standalone PMOS-backed operator surface.
    • The PMOS operator surface is called Ops Check.
    • Ops Check summarizes Development, Production, PMOS, Git and ops truth, and current gaps.
• Pulse PMOS bridge layer
  • What PMOS is
    • PMOS is the bridge and controller between OpenClaw and Pulse PM.
    • PMOS handles task-aware operator actions.
    • PMOS keeps planning and execution connected.
    • PMOS is implemented as bridge code, adapters, tools, doctrine, interpretation, and reference docs.
    • Ops Check is the PMOS operator surface.
    • PMOS makes it possible for Sven and Otto to inspect project state, execute bounded work, write code, and ship changes against the right project lane.
  • Task operations
    • PMOS uses project-explicit task routing.
    • PMOS manages tasks, modules, and sprints as explicit planning entities.
    • PMOS writes planning updates back into the canonical task surface.
    • PMOS is intended to support multiple projects through custom bridges instead of a single hard-wired workflow.
  • Safety model
    • PMOS defaults to Production unless it is explicitly overridden.
    • Development targeting is allowed only through an explicit override.
    • PMOS follows a write, readback, and confirm discipline.
    • PMOS uses preflight checks and guardrails before write-capable operations.
• Pulse PM + product work layer
  • Pulse PM
    • Pulse PM is the canonical live task surface.
    • Pulse PM is where active planning state and work items live.
    • Pulse PM supports users, workspaces, tasks, modules, sprints, auth, and invites.
    • Pulse PM is intended to become a reusable project-management utility for Pulse Product and other future projects.
  • Pulse Product
    • Pulse Product is currently a health and strength conditioning dashboard app.
    • Pulse Product currently runs as a local app surface.
    • Pulse Product is powered by Apple Health and Fitbod data.
    • Simon wants to return to building Pulse Product actively.
    • Pulse PM is intended to manage and execute the work for Pulse Product.
    • Pulse Product is the actual product work being tracked and shipped.
  • Execution units
    • Tasks are the smallest active execution units in the planning system.
    • Modules group related areas of work in the planning system.
    • Sprints organize work into time-bounded planning windows.
    • Closeout and writeback record what was actually done.
• Development execution lane
  • Environment
    • The Development environment runs on the Mac Mini.
    • Development URLs and services stay separate from Production.
    • Terminal and local tooling run on the Mac Mini.
  • Work loop
    • Code changes are made in the Development lane first.
    • Local validation happens before any promotion attempt.
    • Validation should focus on the seam that actually changed.
  • Git boundary
    • Git is the code-state boundary.
    • Git is useful for diff visibility and bounded commits.
    • Git is not the Production restore boundary.
• Production delivery lane
  • Production environment
    • Private Shared is the Production environment.
    • The canonical Production host identity is pulsepm.home.arpa.
    • Production owns live data authority.
    • Production is served on the Ubiquity Private Network for household and private access.
  • Deploy model
    • Only bounded deploys should reach Production.
    • A fresh backup is required before any Production change.
    • Production proof is required after every deploy.
    • Production uses compose-based container deploys on the Mac Mini host.
  • User-facing capability
    • Family members access the Production lane as end users.
    • Production includes user management and authentication.
    • Production includes email and invite flows.
  • Recovery confidence
    • Backups are required for real restore confidence.
    • Backups, not Git, define the restore boundary.
    • The Production stack includes app surfaces, API, PostgreSQL, Redis, RabbitMQ, uploads storage, and internal MinIO.
• Continuity + governance layer
  • Continuity assets
    • Runbooks preserve how risky or repeatable operations should be performed.
    • Prompts preserve execution discipline and operator intent.
    • Docs preserve continuity, policy, architecture, and evidence.
    • The promotion log records bounded Production changes append-only.
    • These continuity assets help Sven and Otto restart without guessing.
  • Memory model
    • Markdown memory is the durable source of truth.
    • QMD is a retrieval and index layer only.
    • Docs are continuity, policy, and evidence, not the live backlog.
• Required truths
  • Local Pulse PM on the Mac Mini is Development.
  • Pulse PM Private Shared is Production.
  • Production owns live data authority.
  • PMOS defaults to Production unless explicitly overridden.
  • Code promotion flows from Development to Production.
  • Routine data refresh normally flows from Production to Development intentionally.
  • Git is not the restore boundary.
  • Backups are the restore boundary.
  • Production proof is required for bounded promotions.
  • For Production-specific bugs, Development proof is not enough.
• Narrative flow
  • Planning
    • Simon identifies work inside Pulse.
    • OpenClaw uses PMOS to inspect or mutate the planning system.
  • Execution
    • Work is executed locally in Development.
    • Changes are validated and checkpointed in Git.
    • A bounded release packet is prepared.
  • Promotion
    • Backups and promotion safeguards are applied.
    • Work is deployed to Private Shared Production.
    • Production proof confirms the change.
  • Closeout + continuity
    • Task writeback and closeout record the result.
    • Memory, docs, and procedures preserve continuity for the next session.