On release branches the bundle's version and the producer's differed, so the
bundle test that asserts they match failed, and released bundles recorded
SNAPSHOT as their provenance. help/*.yaml is now filtered:
version: ${project.version}.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MarketingDemoServer (test sources, not shipped): H2 in memory, mock login
with every marketing permission, the verified starter data, and history
produced through the real actions (readiness, an agent draft on the
scripted provider, review, approval, schedule, a test-transport send).
Run it with the Next UI dev server; see its javadoc.
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>
QbitEmailTransport and MarketingRuntime use com.kingsrook.qbits.email.api
from qbit-email 0.1.0-RC.3; getStatus() keeps its mapping through
EmailApiReadiness.failedChecks (NOT_CONFIGURED only for the base URL and
unsubscribe key; a missing provider or brand address is still REJECTED
at send). qbit-build-parent 2.1.1 allows qbit-email's api by default, so
the temporary email allowances are gone; only the existing assistant
provider SPI allowances remain.
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>
Moves from 0.1.0-SNAPSHOT to the first release candidate. Test schemas
gain the RC's email_provider_sender_address table and the message
from_address_id column where they copy the qbit's DDL.
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>
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