I have this installed on a test VPS and it's operating cleanly.

I've also created a plugin that demonstrates the capability of the lifecycle interceptions hook architecture established in this PR so maintainers can see it in action without having to build their own proof of solution.

https://github.com/tomismeta/continuity-plugin

Please reach out to me if you have any questions or concerns.

I acknowledge the scope is too large to be safely merged/implemented. Before I move forward with breaking the PR up, I wanted to get feedback from the maintainers:

1. Does the way that I framed this architecture (API driven, aliases, hooks to events) align with the architecture/vision? I welcome any feedback?
2. If it's aligned and I do pursue breaking it up, do you have any guidance on how I should approach it? There are two options I'm contemplating.

Option A: Grouped Event PRs (~5 PRs)

• Foundation: lifecycle API, canonical/alias map, validation guards, no runtime wiring.
• Message events: message_received, request_post, message_sending, message_sent, response_error.
• Agent + recall: before_agent_start, agent_end, agent_error, before_recall, after_recall.
• Tool + compaction: before_tool_call, after_tool_call, tool_error, before_compaction, after_compaction.
• Gateway lifecycle + final hardening/docs: gateway_pre_start, gateway_start, gateway_pre_stop, gateway_stop.

Option B: Per-Event Micro PRs (~20 PRs)

• One PR per runtime event (plus a small foundation PR first), e.g. message_received alone, then request_post, etc.
• Each PR includes mapping, wiring, tests, and docs for only that event.

If this is already being implemented through other PRs (or not in alignment with the vision), let me know. Any and all feedback is welcome.

I really need this for my project to integrate with openclaw! let me know what I can do to help

I really need this for my project to integrate with openclaw! let me know what I can do to help

Thanks for checking it out.

As for right now, just waiting on guidance from the maintainers to see if/how I should proceed with breaking this up as smaller PRs (the scope is too big/risky right now). If you have a maintainer contact, would love the plug to have them take a look.

That said, you can use this to build an OpenClaw installation (I've got another agent running on this PR) - would suggest you keep it separate from your primary OpenClaw instance. That said, I've had it up and running smoothly for about a week now with the Continuity plugin installed and working. Let me know if you install it and run into any issues.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Closing this PR as superseded.

Current state from the latest run on March 7, 2026 / March 8, 2026 UTC:

• the branch is conflicting with main again, currently in src/node-host/invoke-system-run-plan.test.ts and src/node-host/invoke-system-run.test.ts
• CI / check is failing on the plugin SDK import boundary lint (lint:plugins:no-monolithic-plugin-sdk-entry-imports), including extensions/feishu/src/directory.ts, extensions/nextcloud-talk/src/channel.ts, and extensions/telegram/src/channel.ts
• CI / checks (node, protocol, pnpm protocol:check) is failing because generated protocol artifacts differ on the merge ref (apps/macos/Sources/OpenClawProtocol/GatewayModels.swift, AgentParams.workspaceDir)

More importantly, the branch no longer reflects the strongest justification for the work. Raw runtime hooks are already exposed on main via api.on(...), so the remaining value here is an abstraction layer, not first-time hook accessibility.

The better follow-up is a fresh docs-only PR from current main that documents:

• existing runtime hook accessibility via api.on(...)
• the available runtime hooks and where they fire
• recommended hook choices for common plugin patterns

That is narrower, more accurate, and much more likely to merge cleanly.