marketing_metric_daily (19th table, system-written, child of the campaign)
holds per-day raw counts and unique actors per stage and event type,
recomputed after every outcome-event insert, update and delete, plus a
Rebuild Results campaign action. MeasurementReport sums the rollup and
counts campaign-wide unique actors with a backend COUNT_DISTINCT instead
of loading every event. MarketingOutcomeImporter lets hosts plug in
analytics sources, run by the Import Outcomes campaign action through
the normal (source, external id) dedupe.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
maxConcurrentAgentRuns and maxModelCallsPerMinute were per-JVM, in memory.
Preflight now fails stale RUNNING runs (no heartbeat for maxRunSeconds
plus 60s) and counts RUNNING runs across all products; the per-minute
limit counts model-call steps in the last minute and waits instead of
failing. Runs record heartbeatAt (new column) on each model call. The
policy's maxConcurrentAgentRuns override is now honoured.
The count-then-start window remains racy; the ConditionalUpdateAction
claim from qqq#1178 (QQQ 4.1.0-RC.7) closes it in a follow-up.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
qbit-crm 0.2.0 renames its tables to crm_* with no compatibility shims
(owner decision via the coordinator), so the gateway uses the snake_case
names directly and drops the camelCase fallback and LEGACY_* constants.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
qbit-crm is renaming its tables to crm_* snake_case. QbitCrmGateway now
resolves each table from the instance at call time, preferring the
snake_case name and falling back to the legacy camelCase one, so either
qbit-crm generation works. Tests run the gateway against both schemes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Move to qbit-assistant-provider-api 0.1.0-RC.12, whose types now live in
com.kingsrook.qbits.assistant.spi (ModelPricing included), and to
qbit-build-parent 2.1.2, which allows that package by default. Drop the
per-repository guardrail allow-lists. qbit-assistant-provider-openai is
only used by tests, so it becomes test scope; hosts that register it add
it themselves.
Fix the stale README status (RCs are on Central; hosted in Voyage#113).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Brings in the qbit-email transport (#11). Conflicts are resolved in
favour of the RC.6/provider-api side, keeping qbit-email.
qbit-email is a new cross-qbit implementation dependency that the
enforced G1 guardrail rejects. It is allow-listed explicitly and
temporarily until qbit-email publishes an API (#13).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Marketing compiled against qbit-assistant internals, and installing it
pulled in the whole assistant runtime. It now depends on
qbit-assistant-provider-api (the provider SPI and ModelPricing) and on the
published qbit-assistant-provider-openai, both 0.1.0-RC.11. The local
OpenAiCompatibleModelProvider is gone, and tests use a local scripted
double, so the full assistant is not needed even in test scope.
Hosts register the published provider through ProviderSettings. Its
provider name is "openai-compatible", so Marketing Policy provider
overrides must use that name.
Also move to QQQ 4.1.0-RC.6 and qbit-build-parent 2.1.0 with the
guardrails enforced. The provider-api packages and provider-openai are
explicitly allow-listed.
Closes#9 (architecture review QRun-IO/qqq#1150, finding F5).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Phase (d) of QRun-IO/qbit-email docs/DESIGN.md section 11. qbit-email is an
optional dependency (0.1.0-SNAPSHOT until its first RC) used through one
adapter class behind a classpath and instance guard; without it the
existing behaviour is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner decisions (2026-10-12): all recommendations accepted. Records the
provider defaults (Claude via qbit-assistant, SES email from qrun.io, no
social transports), the AI-content channel policy (owned channels with
disclosure, release notes allowed, community channels not allowed) and a
USD 25 monthly cost limit; the starter data carries the same values.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HIGH:
- An edit through the UI or API passes the id as a String, so the content
customizer's old-record lookup missed. The edit then skipped the hash
recompute, the revision, approval invalidation and the status guard, and
edited text could go out under the old approval. Ids are now normalized,
the old row is re-read when it is missing, and the update errors instead
of failing open. Execution also compares the approval with a hash
recomputed from the fields it is about to send.
- One failing execution (a CRM outage, a malformed scope, a channel with no
type) aborted the worker batch on every run and starved every later
execution. Each execution is now isolated: a failure before the claim
blocks it with the reason; a failure after the claim leaves it Running for
its lease to expire into reconciliation. Recipient scopes are validated
at submit and approve time.
MEDIUM:
- The policy fails closed. Without the default row, or without an explicit
"on", the agent and execution are off. Configuration Status shows the
policy state.
- The channel hourly rate and the agent budgets are counted as the system
user, so record locks can't hide other products' usage.
- The agent's write tools need the requester's marketing.write, and the agent
revises only content that is still a Draft.
- The entry points of CRM results, readiness checks and starter data check
their own permission. CRM activities are written with the user's CRM
permissions (ENFORCE).
- Closing or downgrading an open blocker finding needs
marketing.approve.hasAccess, whether through the action, the table or the
API.
- Approve pins the content hash shown on the Review screen. Content that
changed before execute is skipped ("review it again").
ReviewFixesTest covers each fix. Fixtures create the default policy row.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- README: what the qbit does, how to install it, permissions, the UI, and an
honest table of what is implemented versus what is not configured.
- docs/DESIGN.md:
- the patterns reused from qbit-assistant, the QQQ AI tool kernel and core
permission enforcement, the existing qbits, qbit-crm, QQQ messaging and
the ESB / Quick Search
- the data model
- content, revisions and approval
- execution and the transports
- measurement
- the CRM integration
- the agent and its tools
- the configuration status
- docs/OPERATIONS.md: every setting, the policy row, the schema workflow, the
credentials to configure later, run-books (publishing, blocked and ambiguous
executions, the kill switch, recording outcomes, agent runs), and the scale
limits stated plainly.
- docs/STARTER-DATA.md: the three products' readiness, the sources verified
on 2026-10-12, the disputed claims, and the starter campaigns.
- CLAUDE.md / AGENTS.md: the architecture and the generated-code rule.
- Tests use obviously fake key strings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tests for the required checks, and the fixes they drove:
- Unauthorized access is denied with core permission enforcement on.
Preparation, approval, execution and the agent need separate permissions.
The optional product security key bounds what users and the agent's tools
see.
- Drafts are made without publication authority. The agent has no approve,
schedule or send tool. A draft that cites a non-released claim gets a
blocker finding, which stops approval.
- Approval is invalidated by any approved-field edit, including a schedule
change. Status and approval rows can't be forged.
- Pause, resume and cancel. Duplicate scheduling and runs are refused.
Ambiguous outcomes are reconciled or decided by a person and never retried
blindly. Repeats are deduplicated by the idempotency key. Retries happen
only when the request was certainly not sent. Expired leases need
reconciliation.
- At execution time: the kill switch, the schedule, consent and suppression,
the bulk limit, channel AI-content rules, and unconfigured transports.
- Outcome events are deduplicated by (source, external id). Raw events and
unique actors are reported separately, and uninstrumented metrics show as
"Not measured". CRM import is idempotent, and leads are qualified only by
an explicit rule.
- Missing provider: the run fails with a plain reason and manual work still
runs. Provider errors are retried or failed by kind, and no secret appears
in errors. Budgets, the concurrency limit, cancellation and the model-call
limit are enforced.
- Persistence across a restart, on the RDBMS module over a file-backed H2
database created from the shipped DDL.
- The OpenAI-compatible provider is tested against a local HTTP fixture.
Fixes:
- Service entry points run as trusted internal work after their own
permission check, the same way QQQ trusts nested calls. Agent tools still
force PermissionEnforcement.ENFORCE.
- Content status and authorType are managed rather than required, and
productId is derived.
- Schedules are kept to the second, so stored values hash the same as
approved ones on every database.
- The Result screen lists skipped records with their reason.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The first version of qbit-marketing. It manages products and their evidence,
campaigns, content with revision history, exact human approval, durable
execution through transports, measurement, and a marketing agent. Everything
lives in 18 standard marketing_* tables inside the host's QQQ app.
- Model: products, audiences, evidence sources, claims (released / planned /
unverified / disputed), campaigns, channels with their rules, content and
immutable revisions, approvals, executions and attempts, test deliveries,
agent runs and steps, findings, metrics, outcome events and the policy.
scripts/generate-model.py generates the entities, enums and DDL from one
spec.
- Approval binds a hash of the text, destination, recipient scope, schedule
and channel. Any edit invalidates it, sends the content back to draft and
blocks pending executions. System-written tables are read-only and are
guarded so that only Marketing's services write them.
- Execution: idempotency keys, leases, retries with backoff only when the
request was certainly not sent, and no blind retry of ambiguous outcomes
(reconcile, or let a person decide). Every send re-checks the kill switch,
approval, schedule, channel, transport, AI-content rules, rate limit,
consent and suppression. A controlled test transport and a QQQ messaging
email transport are provided.
- Agent: qbit-assistant's model-provider SPI (Anthropic, scripted) plus an
OpenAI-compatible provider. Narrow typed tools run as the user with
permission enforcement, inside the untrusted-data envelope, and with
redaction. The tools can draft and record findings but cannot approve or
send. Runs are bounded and recorded with their usage and cost.
- CRM: a narrow gateway SPI with a qbit-crm adapter. Results are imported as
outcome events, and leads are qualified only by a campaign's explicit rule.
- UI: the app home dashboard, record widgets, and streamed-ETL record actions;
the nav holds only the main and settings tables.
- Starter data: QQQ, gclo and MarkdownViewr for Windows, verified 2026-10-12.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Maven scaffold (qbit-build-parent 2.0.0, com.kingsrook.qbits, <revision>
versioning, qqq 4.1.0-RC.4 BOM, JaCoCo gate), QBit config and producer,
CircleCI qqq-orb pipeline, and the standard repository files.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
james.maesandClaude Opus 5.5