How To Run The HASMaster Scenario Pipeline In Paperclip

Use Paperclip as the control-plane view for the HASMaster scenario pipeline while keeping OpenClaw, LangGraph, and optional n8n in their current roles.

Outcome

  • One Paperclip company for HASMaster workflow operations.
  • One project for the scenario pipeline.
  • One parent issue per scenario.
  • One child issue per workflow gate so runtime state stays readable.
  • One visible issue history that reflects LangGraph execution and optional n8n wrapper events.

Audience and Scope

AudienceHASMaster operators and Home Lab admins
DifficultyIntermediate
Estimated Time30 to 60 minutes for the first working pipeline
AssumptionsPaperclip is already deployed and the orchestration stack is under your control

Before You Start

  • Paperclip is reachable on your LAN.
  • The orchestration stack already includes the Paperclip bridge support.
  • You are publishing to staging, not production.
  • You want visibility first, not a full replacement for every wrapper workflow.

Hardware and Software

Core Systems

  • Paperclip
  • OpenClaw
  • LangGraph worker
  • Optional n8n wrapper flows

Local References

  • Paperclip local documentation
  • Agent workflow orchestration documentation
  • HASMaster content routing rules

Step-by-Step

Step 1: Create the Paperclip structure

Objective: Mirror the real HASMaster pipeline in Paperclip so each workflow gate can report its own state.

Use these names for the first working setup:

Company: HASMaster Ops
Project: Scenario Pipeline
Bridge agent: HasmasterWorkflowBridge
Parent issue: SCN-042 | Smart Entry Lighting
Child issue: WF-200-01 | Intake and Approval
Child issue: WF-200-02 | Stage Review
Child issue: WF-200-03 | Publish Preflight

Verification: You can see one scenario parent issue with three child issues in the project board.

Common failure and fix: If the board feels noisy or confusing, stop reusing one issue for multiple workflow gates.

Step 2: Load the bridge token and endpoint

Objective: Make the LangGraph worker capable of patching Paperclip issue state.

Update the orchestration stack with these values:

File: /mnt/nas_docker_apps/agent-workflow-orchestration/stack.env
PAPERCLIP_ENABLED=true
PAPERCLIP_API_URL=http://paperclip:3100/api

File: /mnt/nas_docker_apps/agent-workflow-orchestration/secrets.1password.env
PAPERCLIP_API_KEY=op://HomeLab/paperclip-agent-api-key/password

Verification: The orchestration stack starts cleanly and the worker has access to the API URL and bearer token.

Common failure and fix: If Paperclip never updates, confirm the worker can resolve the API URL from inside the container and that the bearer token belongs to the right company.

Step 3: Run LangGraph against a child issue

Objective: Attach one workflow run to one Paperclip child issue so issue status changes reflect real execution.

Runtime context payload:

{
  "paperclip": {
    "enabled": true,
    "issue_id": "REPLACE_WITH_WF_200_02_ISSUE_ID",
    "run_id": "scn-042-stage-review",
    "start_status": "in_progress",
    "success_status": "done",
    "error_status": "blocked"
  }
}

Example request:

curl -sS -X POST http://192.168.1.200:28092/workflows/basic \
  -H "Authorization: Bearer ${LANGGRAPH_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "task": "Run WF-200-02 for SCN-042 and explain the current lifecycle gate.",
    "runtime_context": {
      "paperclip": {
        "enabled": true,
        "issue_id": "REPLACE_WITH_WF_200_02_ISSUE_ID",
        "run_id": "scn-042-stage-review",
        "start_status": "in_progress",
        "success_status": "done",
        "error_status": "blocked"
      }
    }
  }'

Verification: The target child issue moves into progress at start, then finishes as done or blocked with a readable comment trail.

Common failure and fix: If nothing syncs, re-check the issue identifier and verify that Paperclip sync is enabled for the run.

Step 4: Use n8n only for wrapper events

Objective: Keep n8n only where it still adds value, such as approvals, schedules, waits, or multi-system fan-out.

Send wrapper-level status updates to this endpoint:

POST /integrations/paperclip/issue-events

{
  "enabled": true,
  "issue_id": "REPLACE_WITH_WF_200_03_ISSUE_ID",
  "run_id": "scn-042-publish-preflight",
  "status": "blocked",
  "comment": "Publish preflight is waiting for operator approval in #publishing."
}

Verification: Approval holds, publish waits, and similar wrapper events appear in the right child issue without duplicating LangGraph output.

Common failure and fix: If the issue history becomes repetitive, keep LangGraph responsible for reasoning and outputs, and keep n8n responsible for waits, approvals, and side effects.

Step 5: Decide whether you still need n8n

Objective: Keep the stack as simple as possible without losing the orchestration features you actually use.

Use these decision rules:

If your goal is visibility:
OpenClaw -> LangGraph -> Paperclip

If your goal is approvals, schedules, waits, and external-system choreography:
OpenClaw -> LangGraph -> n8n wrapper -> Paperclip

Verification: You can explain exactly why n8n still exists in the flow, or remove it from pipelines that only needed visibility.

Common failure and fix: Do not keep n8n in the middle just because it is already there. Keep it only where it adds operator or workflow value.

Validation Checklist

  • The company and project exist in Paperclip.
  • The bridge token is loaded into the orchestration stack.
  • A child issue moves to in progress when a workflow run starts.
  • The same child issue finishes as done or blocked with a readable comment.
  • Optional n8n wrapper events appear only where waits or approvals actually occur.

Operations and Maintenance

  • Keep one parent issue per scenario and one child issue per workflow gate.
  • Rotate the Paperclip bridge token through 1Password instead of hard-coding it into Portainer or stack files.
  • Update the guide if workflow identifiers or bridge payloads change.

Troubleshooting and Rollback

Check these values first if Paperclip does not update:

PAPERCLIP_ENABLED=true
PAPERCLIP_API_URL=http://paperclip:3100/api
PAPERCLIP_API_KEY=valid bearer token
Child issue ID=correct target issue

docker logs -n 200 agent-workflow-langgraph

Rollback: Disable Paperclip sync in the orchestration stack and run the workflows normally until the bridge is corrected.

Source Links

/mnt/nas_docs/Applications/AI-Services/Paperclip/overview.md
/mnt/nas_docs/Applications/AI-Services/agent-workflow-orchestration/overview.md
/mnt/nas_docs/Architecture/openclaw-hasmaster-200-discord-workflow-topology.md
/mnt/nas_docs/Architecture/openclaw-hasmaster-200-implementation-matrix.md
https://docs.paperclip.ing/start/core-concepts
https://docs.paperclip.ing/api/overview
https://docs.paperclip.ing/api/activity

My Implementation Notes

This guide matches the current Home Lab pattern: Paperclip for visibility, OpenClaw for operator interaction, LangGraph for workflow logic, and n8n only where wrapper orchestration still adds value.