Technical rollout plan

Delivery Twin on OpenClaw

A local-first Delivery Twin distribution built on pinned upstream OpenClaw, a corporate configuration profile, a Delivery Twin skill/plugin pack, and a wrapper CLI for repeatable client onboarding.

OpenClaw Layering Start A Project Current Review Surface
Branch: pedro/split-core-and-client Last updated: 2026-06-25 Slack via slack-router Telegram direct to delivery-twin

Plan Baseline

Delivery Twin becomes the chat and command layer for the existing Delivery Hub workflow. The durable record remains Azure DevOps plus Delivery Hub specs, decisions, open questions, work packages, and implementation plans.

Repository model

Core and Client stay separate

Core owns reusable workflow capability. Client owns Canford-specific product intent, delivery evidence, generated reports, and runtime bindings.

Agent model

delivery-twin runs the workflow

delivery-twin coordinates runbooks, reads the right source files, produces workflow artifacts, and reports concise status back to chat.

Channel model

Slack and Telegram are entry points

Slack stays routed through slack-router. Telegram routes directly to delivery-twin. Both use the same command grammar.

OpenClaw Layering

Delivery Twin is layered on pinned upstream OpenClaw. The reusable delivery behavior lives in corporate configuration, a Delivery Twin skill/plugin pack, and a wrapper CLI.

Delivery Twin distribution layers Pinned upstream OpenClaw runtime, gateway, sessions, tools Corporate configuration profile models, paths, policies, logging Delivery Twin skill/plugin pack runbooks, instructions, connectors Wrapper CLI: delivery-twin install, doctor, attach, run Enterprise installer
Core package

Reusable capability

Command grammar, OpenClaw agent roles, runbook bindings, safety policies, instruction patterns, templates, and neutral documentation belong in Core.

Client workspace

Client-specific truth

Canford specs, open questions, decisions, ADO evidence, generated reports, channel bindings, and review links stay in the Client workspace.

Target Architecture

The company laptop is the operating boundary. Client workspaces and local indexes stay local. External exits are limited to company systems, Git remotes, Slack or Telegram, and the enterprise LLM route.

Local-first architecture with controlled exits Company laptop Delivery Twin Core OpenClaw layer skills, instructions, policies Client workspace repos, specs, reports indexes, graph context Slack Router Slack triage and relay delivery-twin planning and delivery work Azure DevOps Git remotes Slack / Telegram Enterprise LLM

OpenClaw Installation

Installation should feel like a product bootstrap, not a manual setup note. The wrapper prepares the environment, writes policy-aware configuration, guides logins, and validates readiness.

Expected command flow

delivery-twin install
delivery-twin doctor
delivery-twin login devops
delivery-twin login slack
delivery-twin login telegram
delivery-twin login llm
delivery-twin attach --client canford-law --repo REPO_URL --board BOARD_URL

Doctor checks

  • OpenClaw version and pinned runtime are present.
  • Core path and Client workspace root are separate.
  • Required secrets exist outside Git-tracked files.
  • Enterprise LLM route is configured.
  • Slack and Telegram routing matches the channel plan.

Configuration shape

{
  "deliveryTwin": {
    "openClaw": "pinned-upstream",
    "coreRoot": "~/.delivery-twin/core",
    "clientsRoot": "~/.delivery-twin/clients",
    "defaultClient": "canford-law",
    "externalPostsRequireHumanConfirmation": true,
    "personalProviderFallback": false
  }
}

How To Start A New Project

This flow starts after the Core and Client split is stable, the Core release is pinned by the Client, and strict validation passes through the Core generator.

New client attach

Operator flow

  1. Create a client workspace under ~/.delivery-twin/clients/{client-name}.
  2. Attach Azure DevOps project and repository URLs.
  3. Sync or register the implementation repositories.
  4. Ingest backlog structure, active tags, specs, decisions, and open questions.
  5. Build local indexes and graph context for targeted retrieval.
  6. Generate the first delivery brief, technical map, risk list, and question queue.
First useful output

Client delivery brief

  • Product area map and current backlog shape.
  • Repositories, entry points, tests, and key documentation.
  • Open questions by owner and needed-by date.
  • Delivery risks with source links.
  • Suggested first commands: questions, queue AI-Task, status latest.

Slack And Telegram Commands

The same action names work in both channels. Slack uses /delivery-twin through slack-router. Telegram uses /delivery_twin directly against delivery-twin.

Channel Route Default behavior
Slack /delivery-twin -> slack-router -> delivery-twin when deeper work is needed. Cheap triage, concise replies, no broad repository reads unless escalated.
Telegram /delivery_twin -> delivery-twin. Direct delivery workflow commands for trusted operator use.
Product Owner

Open-question flow

  • questions lists active questions with owners and needed-by dates.
  • question <ref> shows one question with context and source links.
  • answer <ref> <answer> captures intent and updates the durable source first.
  • ask-client <ref> <request> drafts a client follow-up.
Delivery workflow

Runbook commands

  • queue <tag>, status <id>, and run-report latest are read-only by default.
  • refine, spec, research, slice, and task run Delivery Hub paths.
  • review supports PR, test-gap, and documentation-impact review.

Token Use

The split lowers normal command cost by loading stable Core rules plus targeted Client facts, instead of sending broad mixed-repository context for every chat turn.

Routine commands

Small context

Read one question, one spec section, one decision entry, one work package, or one graph query result when that is enough.

Migration work

Temporary increase

Core promotion, pin updates, CI checkout, and boundary debugging need both Core and Client evidence until the release path is stable.

Tracking

Measure per command

Log command, client id, Core pin, files loaded, graph queries, model, input tokens, output tokens, and router versus worker path.

Roadmap

Short phases keep the work sequenced without turning this plan into a detailed implementation backlog.

Phase 1

Complete the Core and Client split: tag Core, update the Client pin, run strict Core-backed portal validation, and settle the CI checkout path.

Phase 2

Package Delivery Twin: pinned upstream OpenClaw, corporate config, skill/plugin pack, wrapper CLI, installer, and doctor checks.

Phase 3

Enable new client onboarding: attach project, connect repositories, ingest backlog, build local indexes, and generate the first delivery brief.

Phase 4

Turn on Slack and Telegram commands, starting with open-question handling, queue summaries, status, and run-report checks.

Phase 5

Expand delivery support with PR review, standup reporting, schedule planning, risk summaries, and workflow health reporting.

Controls

The plan keeps the current Delivery Hub authority model. Chat can start or summarize work, but durable changes must land in the correct source file or system.

Risk Control
Client data enters reusable Core. Promote Core deliberately and keep Canford specs, questions, reports, review URLs, ADO evidence, and generated context in Client.
Chat answers bypass source files. Capture answers in the related spec or decision first. Then update the open-question register with a resolution link.
Slack posts too much sensitive content. Route Slack through slack-router, use summaries and links, allowlist channels, and require human confirmation before external posting.
Runtime config becomes a security assumption too early. Treat the current OpenClaw setup as a functional proof path. Harden identity, secrets, provider routing, and channel permissions before client-sensitive rollout.