@caddis/cli 0.4.20 → 0.4.22

package/bundles/antigravity-plugin-extras/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "caddis-extras",
-  "version": "1.3.31",
+  "version": "1.3.33",
   "description": "caddis-extras — the long-tail skills for the Antigravity (agy) caddis plugin; install alongside caddis for the full set."
 }

package/bundles/antigravity-plugin-extras/skills/hld/references/gold-standard-hld.md

@@ -1,7 +1,7 @@
 ---
 type: design
 status: current
-feature: invoice-composition-replacement
+feature: britebill-replacement
 creation-agent: caddis
 Original Author: Antigravity
 Creation Date: 2026-09-19T13:35:00Z
@@ -12,31 +12,31 @@ Last Model Used: gemini-3.8-flash
 ---
 
 <!--
-GOLD STANDARD REFERENCE for the hld skill.
-This is a real HLD whose organisation-specific facts (company, vendors, hosts, paths, customer
-volumes) were replaced with neutral ones so it can ship publicly. Everything the skill copies
-from it is unchanged: the 8-section structure, heading numbering, the diagram types and their
-styling, the ID schemes (SYS_nn, INT_nn, REQ-nn), and every table's columns. Match THAT, not
-the domain.
+GOLD STANDARD for the hld skill. Match its structure, heading numbering, diagram types and
+styling, ID schemes (SYS_nn, INT_nn, REQ-nn) and table columns exactly.
+ACCOUNTS_PER_RUN, BATCH_HOST, PDF_TOTAL and SECONDARY_SCHEDULES stand in for real, measured
+figures and names in the source HLD; they are withheld here only. A generated HLD must state
+the REAL number or name in every such place - never a placeholder, never a vague 'many'.
+Exact figures are what make the SLA and parity claims checkable.
 -->
 
-# High-Level Architecture (HLA): Invoice Composition Replacement Platform
+# High-Level Architecture (HLA): BriteBill Replacement Platform
 
 ## 1. Executive Summary
 
 ### 1.1 Initiative Goal
-The Invoice Composition Replacement Platform replaces the proprietary third-party invoice composition system that a telecommunications operator uses for fixed-line billing.
+The BriteBill Replacement Platform replaces the proprietary third-party BriteBill invoice composition system used for fixed-line customer billing. 
 
 This platform achieves the following primary business goals:
 - It eliminates third-party licensing costs, proprietary dependencies, and vendor software lock-in.
 - It provides a locally controlled, deterministic, and auditable composition engine.
 - It delivers high-throughput batch generation for four recurring monthly billing cycles: `BR-07`, `BR-14`, `BR-21`, and `BR-28`.
-- It processes approximately 100,000 customer accounts per billing run within a four-hour service level agreement (SLA) window.
+- It processes approximately `<ACCOUNTS_PER_RUN>` customer accounts per billing run within a four-hour service level agreement (SLA) window.
 - It simultaneously produces four synchronized output channels from a single canonical document model: Customer PDF, Print Spool AFP, Mailroom Index JRN, and Digital Portal XML.
 - It guarantees full financial integrity through mandatory, fail-closed automated reconciliation gates.
 
 ### 1.2 Solution Architecture Summary
-The solution operates as a standalone Python-based batch processing engine deployed on host `batch-host-01`. It processes raw billing stream files (`.EN`) from the upstream billing engine, executes financial reconciliation, and renders customer-facing outputs. The engine isolates every run in an immutable staging directory, verifies cryptographic checksums, and publishes outputs atomically only after all financial and population gates pass.
+The solution operates as a standalone Python-based batch processing engine deployed on the dedicated batch host `<BATCH_HOST>`. It processes raw Kenan billing stream files (`.EN`), executes financial reconciliation, and renders customer-facing outputs. The engine isolates every run in an immutable staging directory, verifies cryptographic checksums, and publishes outputs atomically only after all financial and population gates pass.
 
 ### 1.3 Business Value & Operational Outcomes
 - **Cost Reduction**: Complete decommissioning of third-party composition licenses.
@@ -49,12 +49,12 @@ The solution operates as a standalone Python-based batch processing engine deplo
 ## 2. Project Context and Scope
 
 ### 2.1 Background
-The operator's fixed customer billing produces monthly invoices across four staggered billing cycles. The legacy composition workflow relied on an external vendor system. This introduced high annual licensing costs and operational delays whenever regulatory or template changes occurred. The replacement platform moves invoice composition entirely onto internal infrastructure using high-performance open standards.
+Fixed-line customer billing produces monthly invoices across four staggered billing cycles. The legacy composition workflow relied on an external vendor system (BriteBill). This introduced high annual licensing costs and operational delays whenever regulatory or template changes occurred. The BriteBill Replacement Platform moves invoice composition entirely onto internal infrastructure using high-performance open standards.
 
 ### 2.2 Scope
 
 #### 2.2.1 In Scope
-- Ingestion of raw `.EN` tagged-record stream files generated by the upstream billing engine.
+- Ingestion of raw `.EN` tagged-record stream files generated by the upstream Kenan billing engine.
 - Syntactic and structural validation of incoming batch streams with marker-file arrival detection.
 - Transformation of raw stream records into an immutable, strongly typed canonical domain model.
 - Full-population financial reconciliation covering invoice totals, line item aggregates, tax breakdowns, and balance brought forward.
@@ -67,14 +67,14 @@ The operator's fixed customer billing produces monthly invoices across four stag
 - Atomic publication to destination endpoints with isolated staging and late-arriving release markers.
 
 #### 2.2.2 Out of Scope
-- Upstream rating, charging, or billing account balance calculation performed by the billing engine.
+- Upstream rating, charging, or billing account balance calculation performed by Kenan.
 - Direct management or control of physical print-house insertion machinery and postal sorters.
 - Real-time customer web serving; online portals ingest published outputs asynchronously.
 - Probabilistic, generative, or Large Language Model (LLM) components in the financial generation path.
 
 ### 2.3 Architecture Boundaries and Key Assumptions
 - **Deterministic Processing**: All calculations and document renderings produce identical, byte-reproducible outputs for identical inputs.
-- **Local Filesystem Isolation**: Network-isolated execution on `batch-host-01` with zero runtime external API or HTTP dependencies.
+- **Local Filesystem Isolation**: Network-isolated execution on `<BATCH_HOST>` with zero runtime external API or HTTP dependencies.
 - **Fail-Closed Operations**: Any financial discrepancy, unmapped record, or population count mismatch immediately halts the run and prevents output release.
 
 ---
@@ -177,7 +177,7 @@ sequenceDiagram
     Render->>Storage: Write outputs into staging directories
 
     Note over Orch,Targets: Stage 5: Population Audit & Atomic Release
-    Orch->>Audit: Verify population counts (PDF == XML == AFP == 100,000)
+    Orch->>Audit: Verify population counts (PDF == XML == AFP == ACCOUNTS_PER_RUN)
     Orch->>Audit: Seal freeze-manifest.json and compute final SHA-256 digests
     Orch->>Audit: Transition to RunLifecycle::READY_FOR_RELEASE
     Orch->>Targets: Copy verified artifacts to delivery endpoints
@@ -201,12 +201,12 @@ flowchart TD
 
     subgraph Upstream["Upstream Billing Systems"]
         direction LR
-        SYS_01["SYS_01: Billing & Rating Engine<br/>Rating & Billing Lifecycle"]:::existingStyle
+        SYS_01["SYS_01: Kenan Billing Engine<br/>Rating & Billing Lifecycle"]:::existingStyle
     end
 
-    subgraph CorePlatform["Invoice Composition Replacement Platform (batch-host-01)"]
+    subgraph CorePlatform["BriteBill Replacement Platform (BATCH_HOST)"]
         direction LR
-        SYS_02["SYS_02: Composition Replacement Engine<br/>Ingestion, Mapping, Reconcile & Render"]:::newStyle
+        SYS_02["SYS_02: BriteBill Replacement Engine<br/>Ingestion, Mapping, Reconcile & Render"]:::newStyle
         SYS_06["SYS_06: Operations Control Centre<br/>Audit Journal, Sealed Manifest & CLI"]:::newStyle
     end
 
@@ -231,23 +231,23 @@ The table below catalogs all systems and platforms within the solution boundary:
 
 | ID | Application / Component | Application Type | Description | Impacted |
 |---|---|---|---|---|
-| `SYS_01` | Billing & Rating Engine | Billing / Rating | Upstream rating engine producing periodic `.EN` billing stream files. | No |
-| `SYS_02` | Composition Replacement Engine | Batch Engine | Core batch orchestration, mapping, financial reconciliation, and multi-channel rendering engine. | Yes |
+| `SYS_01` | Kenan Billing Engine (Amdocs) | Billing / Rating | Upstream rating engine producing periodic `.EN` billing stream files. | No |
+| `SYS_02` | BriteBill Replacement Composition Engine | Batch Engine | Core batch orchestration, mapping, financial reconciliation, and multi-channel rendering engine. | Yes |
 | `SYS_03` | External Print House & Mailroom Spool | Print Production | Commercial printing facility ingesting MO:DCA AFP spools and JRN insertion records. | No |
-| `SYS_04` | Customer Self-Service Portal | Web Portal | Customer billing portal ingesting structured eBilling XML for web presentation. | No |
+| `SYS_04` | Customer Digital Self-Service Portal | Web Portal | Customer billing portal ingesting structured eBilling XML for web presentation. | No |
 | `SYS_05` | Enterprise Document Archive & Dispatcher | Document Repository | Long-term customer communications repository and email dispatcher ingesting certified PDF invoices. | No |
 | `SYS_06` | Operations Control Centre & Audit Journal | Ops & Governance | Operational monitoring CLI, telemetry aggregator, and sealed run manifest validator. | Yes |
 
-#### 4.2.1 SYS_01: Billing & Rating Engine
-The billing engine calculates customer monthly billing totals, rating, and payment adjustments. At cycle close, it exports raw `.EN` tagged-record stream files to the staging transfer area.
+#### 4.2.1 SYS_01: Kenan Billing Engine (Amdocs)
+The Kenan engine calculates customer monthly billing totals, rating, and payment adjustments. At cycle close, Kenan exports raw `.EN` tagged-record stream files to the staging transfer area.
 
-#### 4.2.2 SYS_02: Composition Replacement Engine
+#### 4.2.2 SYS_02: BriteBill Replacement Composition Engine
 The core processing component implemented in Python. It executes local staging, canonical data mapping, strict financial reconciliation, and parallel document rendering.
 
 #### 4.2.3 SYS_03: External Print House & Mailroom Spool
 Receives binary MO:DCA AFP print spools and JRN insertion index files for postal sorting, physical paper printing, envelope inserting, and mail dispatch.
 
-#### 4.2.4 SYS_04: Customer Self-Service Portal
+#### 4.2.4 SYS_04: Customer Digital Self-Service Portal
 The customer-facing digital web application that parses structured XML invoice streams to present interactive online bill breakdowns.
 
 #### 4.2.5 SYS_05: Enterprise Document Archive & Dispatcher
@@ -262,14 +262,14 @@ The table below details all communication interfaces across the platform boundar
 
 | ID | Type / Protocol | From | To | Description | Connectivity |
 |---|---|---|---|---|---|
-| `INT_01` | SFTP / SMB File Feed | `SYS_01` | `SYS_02` | Tagged-record billing stream (`.EN`) and cycle marker file. | Existing Connectivity |
+| `INT_01` | SFTP / SMB File Feed | `SYS_01` | `SYS_02` | Kenan tagged-record billing stream (`.EN`) and cycle marker file. | Existing Connectivity |
 | `INT_02` | Secure File Transfer | `SYS_02` | `SYS_03` | MO:DCA AFP binary print stream partitioned at source-EN granularity. | New Connectivity |
 | `INT_03` | Secure File Transfer | `SYS_02` | `SYS_03` | Tabular ASCII index files (`.JRN`) containing mailroom insertion records. | New Connectivity |
 | `INT_04` | Secure File Transfer | `SYS_02` | `SYS_04` | Lossless structured XML documents matching customer portal schema. | New Connectivity |
 | `INT_05` | Secure File Transfer | `SYS_02` | `SYS_05` | Certified, byte-deterministic PDF customer invoices. | New Connectivity |
 | `INT_06` | Local File / JSONL | `SYS_02` | `SYS_06` | Append-only execution journal, telemetry events, and sealed manifest. | New Connectivity |
 
-#### 4.3.1 INT_01: Billing Stream & Completion Marker
+#### 4.3.1 INT_01: Kenan Billing Stream & Completion Marker
 Transfers raw `.EN` data files containing account records, billing headers, charge breakdowns, and payment histories. A completion marker file signals batch completeness.
 
 #### 4.3.2 INT_02: MO:DCA AFP Print Spools
@@ -282,7 +282,7 @@ Delivers ASCII index files specifying sheet counts, account identifiers, envelop
 Transfers schema-validated XML documents containing invoice data for online customer self-service viewing.
 
 #### 4.3.5 INT_05: Deterministic PDF Invoices
-Transfers byte-deterministic PDF documents containing vector brand artwork, billing transaction tables, and payment slips.
+Transfers byte-deterministic PDF documents containing vector brand artwork, billing transaction tables, and Giro payment slips.
 
 #### 4.3.6 INT_06: Telemetry & Sealed Manifest
 Emits structured JSONL telemetry and a cryptographic `release_manifest.json` sealing file counts, execution parameters, and SHA-256 hashes.
@@ -304,7 +304,7 @@ The platform provides administrative command-line surfaces for operations and sc
 ## 5. High-Level Data and Storage Architecture
 
 ### 5.1 Host & Working Storage Topology
-The engine executes entirely within a dedicated local filesystem hierarchy on host `batch-host-01`. Every batch run is isolated by unique run and attempt identifiers:
+The engine executes entirely within a dedicated local filesystem hierarchy on the dedicated batch host `<BATCH_HOST>`. Every batch run is isolated by unique run and attempt identifiers:
 
 ```
 <working_root>/<run_id>/<attempt_id>/
@@ -365,9 +365,9 @@ classDiagram
 
 ### 5.3 Multi-Channel Output Volume & Specifications
 Production metrics established during candidate certification (ATT-006 baseline):
-- **PDF Documents**: 100,750 total PDF files (100,000 primary invoices + 750 secondary itemized schedules).
-- **XML Documents**: 100,000 structured customer eBilling files.
-- **AFP Spools**: 32 consolidated MO:DCA print files matching the 32 upstream input batches.
+- **PDF Documents**: `<PDF_TOTAL>` total PDF files (`<ACCOUNTS_PER_RUN>` primary invoices + `<SECONDARY_SCHEDULES>` secondary itemized schedules).
+- **XML Documents**: `<ACCOUNTS_PER_RUN>` structured customer eBilling files.
+- **AFP Spools**: 32 consolidated MO:DCA print files matching the 32 upstream Kenan input batches.
 - **JRN Journals**: 32 postal index files containing 100% field parity with postal insertion machinery.
 
 ---
@@ -382,7 +382,7 @@ The platform security architecture adheres to strict controls defined in `docs/S
 
 ### 6.2 Zero Runtime Network Access
 - No module within `ingestion/`, `mapping/`, `templating/`, or `rendering/` initiates external HTTP or network requests during generation.
-- All fonts, styling assets, and configuration templates reside locally on disk on `batch-host-01`.
+- All fonts, styling assets, and configuration templates reside locally on disk on `<BATCH_HOST>`.
 
 ### 6.3 Working Storage Path Isolation & Traversal Defense
 - File discovery resolves candidate paths and rejects any file whose resolved parent directory escapes the staging root.
@@ -390,7 +390,7 @@ The platform security architecture adheres to strict controls defined in `docs/S
 
 ### 6.4 Privacy and Audit Redaction
 - Domain models override string representations to redact personal customer names and street addresses from log outputs.
-- Upstream customer metadata categories (`FIRSTNAME`, `EMAIL`, `OFFNETID`, `POSTCODE`) are dropped during ingestion mapping.
+- Upstream customer metadata categories (`FIRSTNAME`, `EMAIL`, `OFFNETID`, `EIRCODE`) are dropped during ingestion mapping.
 - Audit manifests record only source file basenames, billing reference numbers, and one-way SHA-256 correlation identifiers.
 
 ---
@@ -401,10 +401,10 @@ The platform security architecture adheres to strict controls defined in `docs/S
 
 | Requirement | Description | Component Implementation | Verification Control |
 |---|---|---|---|
-| `REQ-01` | Ingest `.EN` tagged-record streams | `SYS_02` (`ingestion/en_reader.py`) | Automated parser unit tests and zero-failure batch validation. |
+| `REQ-01` | Ingest Kenan `.EN` tagged-record streams | `SYS_02` (`ingestion/en_reader.py`) | Automated parser unit tests and zero-failure batch validation. |
 | `REQ-02` | Strong financial reconciliation | `SYS_02` (`reconciliation/checks.py`) | Full-population balance reconciliation gate (`reconcile()`). |
 | `REQ-03` | Byte-deterministic PDF rendering | `SYS_02` (`rendering/mupdf_renderer.py`) | SHA-256 byte-identity verification against certified baseline. |
-| `REQ-04` | Multi-channel parity (PDF/XML/AFP/JRN) | `SYS_02` (`mapping/*`, `rendering/*`) | Cross-output population count verification (`100,000` exact). |
+| `REQ-04` | Multi-channel parity (PDF/XML/AFP/JRN) | `SYS_02` (`mapping/*`, `rendering/*`) | Cross-output population count verification (`<ACCOUNTS_PER_RUN>` exact). |
 | `REQ-05` | Atomic release & staging isolation | `SYS_02` (`batch/orchestrator.py`) | Zero output visibility before `READY_FOR_RELEASE` and marker written last. |
 | `REQ-06` | Auditability & run sealing | `SYS_06` (`audit/manifest.py`) | Cryptographic `release_manifest.json` generation. |
 
@@ -416,13 +416,13 @@ The platform security architecture adheres to strict controls defined in `docs/S
 
 | Term | Definition |
 |---|---|
-| `.EN` | Proprietary tagged-record flat file format emitted by the upstream billing engine. |
+| `.EN` | Proprietary tagged-record flat file format emitted by the Kenan billing engine. |
 | AFP | Advanced Function Presentation / MO:DCA binary print architecture used in industrial mailrooms. |
 | JRN | Journal insertion index file coordinating automated paper folding and envelope stuffing. |
 | Byte Determinism | The guarantee that identical inputs rendered with identical parameters yield identical binary SHA-256 hashes. |
 | Fail-Closed | An architectural principle where any detected inconsistency aborts processing before releasing outputs. |
 
 ### 8.2 Reference Documents
-- `<repo>/README.md`: System operational runbook and architecture overview.
-- `<repo>/docs/SECURITY_AND_PRIVACY.md`: Security controls and privacy safeguards.
-- `<repo>/docs/PRODUCTION_CANDIDATE_ATT006.md`: Candidate certification report and benchmark results.
+- `britebill-replacement/README.md`: System operational runbook and architecture overview.
+- `britebill-replacement/docs/SECURITY_AND_PRIVACY.md`: Security controls and privacy safeguards.
+- `britebill-replacement/docs/PRODUCTION_CANDIDATE_ATT006.md`: Candidate certification report and benchmark results.

package/bundles/manifest.json

@@ -2,7 +2,7 @@
   "poolVersion": "1.3.112",
   "bundles": {
     "antigravity-plugin": "1.3.112",
-    "antigravity-plugin-extras": "1.3.31",
+    "antigravity-plugin-extras": "1.3.33",
     "codex": "unknown"
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@caddis/cli",
-  "version": "0.4.20",
+  "version": "0.4.22",
   "description": "Install, update and diagnose the caddis dev harness across every coding agent you use (Claude Code, agy/Antigravity, and more).",
   "keywords": [
     "caddis",