P
AirPilot Catch-Up Plan
Implementation plan - 2026-06-06

Close the WHMCS gap without bloating LibCyberAI.

My plan is to port VilaAI's operator-grade WHMCS behavior into AirPilot in narrow, testable slices. The LibCyberAI worktree should only receive shared safety primitives where they fit its libcyber-only scope.

VilaAI is the donor for WHMCS ops behavior AirPilot is the target platform LibCyberAI stays scoped Verification gates before merge

Phased Plan

Each phase has one deliverable and one verification gate. The order is intentional: smallest direct gap first, broad UI later.

Phase 0Scope lock

Freeze the parity map

Turn the brief into an implementation checklist and decide what belongs in core AirPilot, the WHMCS connector, docs, or LibCyberAI shared code.

  • Confirm canonical WHMCS connector path.
  • Separate merged VilaAI commits from dirty worktree additions.
  • Write acceptance tests before large ports.
Phase 1Highest ROI

Port retroactive promo redemption

Add the missing AirPilot WHMCS capability with a two-phase evaluate/apply flow and idempotent ledger protection.

  • Add tool definitions and model-facing instructions.
  • Add connector endpoint, rule engine, and migration.
  • Test duplicate retries, caps, rejected invoices, and concurrent applies.
Phase 2Safety

Install staged refund policy

Make refund and chargeback pressure a separate path from retention so the assistant does not mix escalation with save offers.

  • Model policy as vendor-configurable playbook text.
  • Add detection and retention suppression tests.
  • Keep final financial authority with configured staff process.
Phase 3Telegram

Port default-polish reply safety

Move from optional polish helpers to a real outbound gate: success sends polished text, failure asks before raw send.

  • Add processed-update claim states and stale retry.
  • Add pending raw-reply state with expiry.
  • Test /nopolish, /cancel, bot-addressed commands, and callback replay.
Phase 4WHMCS UX

Add operator conversation views

Build a WHMCS-native conversation surface over connector logs, with deep links from Telegram and a raw-log escape hatch.

  • Reuse existing log rows where possible.
  • Sessionize by conversation id and time windows.
  • Keep the portal conversation product as the richer SaaS surface.
Phase 5Shared code

Backport only shared primitives

LibCyberAI should receive only generic safety and transport improvements. It should not gain WHMCS billing or promo tools.

  • Evaluate OpenAI transport parity.
  • Evaluate Telegram safety where libcyber operators benefit.
  • Reject WHMCS-specific migrations and admin pages.

Where The Code Goes

The main risk is putting behavior in the wrong layer. This split keeps product scope clean.

AirPilot target layers

A
Core tool registryNew WHMCS tool definitions, policies, and model-facing descriptions.
AirPilot/app/core/tools
C
WHMCS connectorEndpoints, dispatch, migrations, and admin config for panel-local behavior.
whmcs-airpilot
P
PortalOnly add visibility or settings that belong in the SaaS control plane.
portal/src
V
VilaAI donor refsUse as source behavior, not as a bulk copy target.
whmcsModules/vilaai

Variant policy

L
LibCyberAI worktreeKeep single-tenant, BYOK-only, libcyber-only. No WHMCS parity creep.
LibCyberAI
!
Do not fork business logic twiceIf a rule is generic, share it. If it is WHMCS-specific, keep it out of LibCyberAI.
scope gate
T
Transport improvementsCustom endpoint capability handling can be shared if tests prove it does not violate BYOK assumptions.
OpenAI service
G
Telegram safetyDefault-polish gates may be shared if the variant actually sends operator replies through Telegram.
bot layer

Vendor Admin Surface

The WHMCS addon is not the vendor control center. It is the connector installed inside the vendor's WHMCS.

Inside WHMCS addon

1
Connector setupService URL, API key, API secret, department IDs, and chat-widget enabled state.
airpilot_config
2
Connection checkA simple test button verifies the WHMCS install can reach the AirPilot central service.
test_connection
3
Thin event logLast 20 connector event rows for operational sanity checks.
mod_airpilot_event_log

On AirPilot website

V
Vendor portalDashboard, conversations, escalations, knowledge base, how-to library, billing, help, and settings.
/vendor/*
T
Team and authVendor login, profile, invites, team members, enable/disable, and logout.
/api/v1/vendor-auth/*
K
Knowledge and toolsFAQ, knowledge import/sync/reindex, tool list, audit, stats, and vendor config.
/api/v1/knowledge + /tools

Execution Timeline

This is the order I would use if we move from brief to implementation.

Day 0

Create issue/spec from the gap brief

Pin exact acceptance criteria, tool names, schema changes, and which connector copy is canonical.

Spec approved
Days 1-3

Promo redemption vertical slice

Core definition, connector implementation, migration, tests, and model prompt behavior in one reviewable branch.

Tool tests pass
Days 3-5

Refund playbook and Telegram reply gate

Add staged refund semantics, retention suppression, processed-update claims, and raw-send confirmation.

Replay tests pass
Week 2

Operator UI and deep links

Bring WHMCS-native conversation/session views and Telegram links without weakening AirPilot portal architecture.

Manual WHMCS pass
Week 2+

Transport parity and variant review

Add or reject xhigh/Responses/SSE behavior per target, then decide the LibCyberAI backport list.

Variant clean

Drilldown

Click a workstream to see what I would actually build and how I would verify it.

1st
Implement first because it is concrete, bounded, and directly missing from AirPilot WHMCS.

Promo redemption vertical slice

Add two AirPilot WHMCS tools: evaluate first, apply second. The apply path needs an idempotency key, ledger status, cap checks, and concurrency protection.

evaluate_promo_redemption -> apply_promo_redemption Tests: rejected invoice, already credited, duplicate retry, concurrent apply, cap exceeded

Risks I Would Control

These are the places I would slow down and verify before calling it done.

Connector drift

AirPilot appears to have more than one WHMCS connector copy. Pick a canonical path, then mirror intentionally.

Idempotency

Promo application must tolerate duplicate model calls, retry storms, and concurrent admins.

Telegram race windows

Processed-update state must not mark an update done before the operation actually succeeds.

Variant contamination

LibCyberAI should remain libcyber-only. Shared safety is fine; WHMCS business logic is not.