23 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
james.maes	fda9ad0de6	Merge pull request 'feat: scene 2 foundations: version 1 compatibility corpus, coverage and fuzz gates, preview ports (P0, P13, P6a)' (#13) from feat/scene2-foundations into develop	2026-11-12 15:15:18 +00:00
james.maesandClaude Fable 5.2	c6aa0bf6b0	feat(foundation): preview, diagnostic and render target ports with registration hooks (P6a) ... The contracts the preview, bridge and render target packages plug into. No label prints differently and no existing host adapter changes. GenerationPorts: - Diagnostic (with Severity): a code from a closed vocabulary, an author element id, a box and named integers. It has no field that holds free text. - PreviewRequest, PreviewPage and Preview, and IsolatedRenderer.preview as a default that refuses, so an adapter written before it compiles unchanged. - 15 version 2 FailureCode values after the 13 released ones, and RenderException(FailureCode, Diagnostic) beside the existing constructor. - Integer targetDpi on RenderRequest (absent, 203, 300 or 600); the seven-argument constructor is kept and nothing reads the value yet. Registration points, each an empty class that is already called: GenerationPreviewProcesses, GenerationAssetProcesses, GenerationUpgradeProcesses and GenerationAssetTables from the producer, and GenerationPreviewWidget.section(table) from GenerationTables. Bridge: IsolatedRendererBridge maps any FailureCode name from a 0.1.0 worker to a typed refusal, so growing the enum alone would have widened what such a worker can name. The 13 released codes are now the set a 0.1.0 worker may name; BridgeTest asserts the other 15 stay generic. Tests: record validation, default refusals, source compatibility of the existing constructors, and that the producer registers exactly the tables, processes, choices, widgets and template sections it did before (the lists were captured from the untouched v1.1.0-RC.2 tag). Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-11 17:28:43 -06:00
james.maesandClaude Fable 5.2	3ba676106f	build(coverage): gate renderer and bridge coverage at baseline; seeded mutation campaigns (P13) ... Coverage gates: - renderer and bridges/renderer gain JaCoCo (prepare-agent, report, check at verify) with a bundle rule at the measured baseline, rounded down: renderer 94% instructions and 91% lines, bridge 85% instructions and 82% lines. - New code is held to 100% line coverage from its first commit: packages com.kingsrook.qbits.renderer.scene2 and below, AssetInspector, ZplRaster, and the new foundation classes the label layout design names. The rules match nothing until those exist, so later packages do not edit these poms. - The foundation's 85% instruction and 90% class rule is unchanged. Fuzz scaffolding: - MutationCampaign in each module's test tree: a seeded, bounded mutation harness with no clock and no unseeded randomness; a finding replays from its seed and iteration. - One campaign per module in the normal test phase: what the version 1 scene parser accepts is a version 1 scene (checked by a second parser), and what the host printer gate accepts holds only the renderer's command set. - docs/security/fuzzing.md: targets, properties, limits, seeds and replay. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-11 17:28:42 -06:00
james.maesandClaude Fable 5.2	ea776391ca	test(renderer): version 1 scene compatibility corpus from v1.1.0-RC.2 (P0) ... Version 1 scenes (qqq-zpl-scene/1) are frozen. This adds 42 render requests and the exact ZPL the released renderer returned for each, so later work can prove that labels already printing are untouched. - renderer/src/test/resources/compat-v1: cases, stored ZPL, SHA256SUMS and a README with provenance and rules. The bytes were produced by the source of tag v1.1.0-RC.2 (e9ffba48), not by this branch, and the same test passed against the tag on Temurin 21.0.12 (Windows) and 21.0.9 (the CI image). - renderer ZplSceneOneCompatibilityTest: fails on the first differing byte, on a manifest that does not name exactly the cases, and on a corpus that misses a version 1 element type, property or resolution. - bridges/renderer ZplSceneOneCompatibilityTest: every stored output has its manifest hash and passes the unchanged ZplOutputPolicy. It reads the renderer's directory in place, so there is one copy of the corpus. Covered: the four shapes Forge publishes at 203 and 300 dpi (GS1-128 with fit and quiet, text in font 0, rasterText with fontAsset), the README and BARCODE-FIT.md examples, and one scene per element and option at 203, 300 and 600 dpi. All values are synthetic. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-11 17:28:25 -06:00
james.maes	228931a937	Merge pull request 'fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only' (#9) from fix/aurora-full-page-writes into develop	2026-11-10 22:57:56 +00:00
james.maesandClaude Fable 5.2	cfbf0744f9	fix(postgres): accept full_page_writes off on Amazon Aurora PostgreSQL only ... Generation qualification refused every Amazon Aurora PostgreSQL server: Aurora always reports full_page_writes = off and has no parameter to change it, because its storage layer does not write torn pages. The settings query now also returns to_regprocedure('aurora_version()') IS NOT NULL (true on Aurora, false on stock PostgreSQL, never an error). full_page_writes = off is accepted only when that is true. Stock PostgreSQL must still report it on, and fsync on, synchronous_commit on or remote_apply and every other check are unchanged on both. The refusal text now says full-page writes are not required on Aurora. Tests run on a real postgres:17 engine whose settings are really changed; only Aurora is simulated, by creating a function named aurora_version() in the test database. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-09 20:25:55 -06:00
james.maes	e762dac5d5	Merge pull request 'build(renderer): build engine and service images from a released version' (#7) from fix/renderer-images into develop	2026-11-09 02:39:57 +00:00
james.maesandClaude Sonnet 5.5	e19feb01a8	build(renderer): build the engine and service images from a released version ... Both Dockerfiles copied 0.1.0-SNAPSHOT jars that the reactor no longer produces (version is ${revision}), so neither built a released version. They now resolve the released qbit-document-renderer and qqq-remote-renderer-transport (and their runtime libraries) at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the QRun-IO Gitea Maven registry and Maven Central, refusing SNAPSHOT and local (*forge*) versions. The reviewed hardening is unchanged: digest-pinned BUILD_IMAGE/JAVA_IMAGE, non-root 65532, read-only-root friendly, Zint built from vendor/. The reactor build context is no longer needed. Adds IMAGE-PUBLISH.md (repeatable build/scan/publish steps and the 1.0.0 pins) and image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published image). Images for 1.0.0 were built, smoke-tested over mTLS and published to GHCR under gg-engineering by hand; no workflow publishes images. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-08 20:07:14 -06:00
james.maes	889296d8f5	Merge pull request 'build(deps): align with Gitea registry (parent 2.2.1, QQQ 4.1.0-RC.26)' (#6) from deps/align-gitea into develop	2026-11-07 19:07:22 +00:00
james.maesandClaude Opus 5.5	e085859a25	build(deps): move qqq.version into <properties> ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-07 18:59:59 +00:00
james.maesandClaude Opus 5.5	4f850c2cf3	build(deps): align with Gitea registry (parent 2.2.1, QQQ 4.1.0-RC.26) ... bridges/printing/pom.xml: qqq.version: 4.1.0-RC.22 -> 4.1.0-RC.26 bridges/printing/pom.xml: qbit-record-files.version: 0.1.0-RC.1 -> 0.4.0-RC.1 bridges/printing/pom.xml: qbit-printing.version: 1.0.0 -> 1.2.0-RC.1 bridges/record-files/pom.xml: qqq.version: 4.1.0-RC.22 -> 4.1.0-RC.26 bridges/record-files/pom.xml: qbit-record-files.version: 0.1.0-RC.1 -> 0.4.0-RC.1 bridges/scripting/pom.xml: qqq.version: 4.1.0-RC.22 -> 4.1.0-RC.26 bridges/scripting/pom.xml: qbit-scripting.version: 1.0.0 -> 1.1.0-RC.3 foundation/pom.xml: qqq.version: 4.1.0-RC.22 -> 4.1.0-RC.26 pom.xml: parent -> 2.2.1 pom.xml: added qqq.version=4.1.0-RC.26 (parent BOM import) pom.xml: revision -> 1.1.0-SNAPSHOT Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-07 18:59:01 +00:00
james.maes	2dcee6fbea	Merge pull request 'ci: pin shared workflow to v1' (#4) from ci/pin-v1-develop into develop	2026-11-06 23:11:03 +00:00
james.maes	98eef612d0	Merge pull request 'Document Generation 1.0: fix renderer tests; pin released Record Files, Scripting and Core RC.22' (#5) from kof22/renderer-fix into develop	2026-11-06 20:19:06 +00:00
james.maesandClaude Sonnet 5.5	cb420158ba	release: prepare Document Generation 1.0 (released Record Files, Scripting, Core RC.22) ... Pin QQQ Core 4.1.0-RC.22, Record Files 0.1.0-RC.1 and Scripting 1.0.0 in place of the SNAPSHOT placeholders, and replace the unreleased-checkpoint text. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-06 13:11:27 -06:00
james.maesandClaude Sonnet 5.5	10b3a716b5	fix(renderer): refuse barHeight where it has no effect; check the provider at the family version ... barHeight was advertised and accepted for every encoder although the sixteen fixed-geometry encoders (matrix symbols and postal four-state codes) ignore it. It is now neither advertised nor accepted for them and is refused with the closed code UNSUPPORTED_BARCODE_OPTION, as is GS1 DataBar in stacked mode. The worker maps that code through, and VALIDATE refuses literal unsupported options before any data exists. The patched OpenHTML qualification compared against the old literal version; it now compares against the family version surefire passes in. All 174 renderer tests pass, including the four that failed. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-06 13:11:26 -06:00
james.maesandClaude Opus 5.5	063b1e8136	ci: pin shared workflow to v1 ... Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-06 15:55:32 +00:00
james.maes	72de6f87e5	Merge pull request 'Make the reactor root the single version source; publish vendored OpenHTML at the family version' (#1) from kof22/single-revision into develop	2026-11-06 15:35:27 +00:00
james.maes	97a4ac6c92	Merge pull request 'ci: use shared ci-workflows Maven workflow' (#2) from ci/ci-workflows into develop	2026-11-06 15:34:32 +00:00
james.maes	d3c0062343	Merge pull request 'feat(authoring): rename document types, stock and templates natively' (#3) from feat/definition-rename-20261106 into develop	2026-11-06 15:32:50 +00:00
james.maesandClaude Fable 5.1	313f081026	feat(authoring): rename document types, stock and templates natively ... Add DocumentDefinitionService.rename and the native authoring actions document_generation_{type,stock,template}_author_rename. The form loads the current name and saves only the trimmed name; names must be nonblank, at most 200 characters and free of control characters. The configure permission is checked at discovery and again at save, and the native UpdateAction keeps the host's field-level audit. GenerationStore.update now admits an id+name-only write for type and stock rows, so geometry, bindings, drafts, published revisions and queued pins stay immutable. No schema change. Carried locally by GG Forge as definition-rename.patch (pin 0.1.0-forge.ee782b7d6ea8-rename1); upstreamed so a published release can replace that pin. The prepare-step selection message is generalised to cover type and stock rows. Docs: AUTHORING.md describes the action, README and RELEASE-STATUS record the addition and its verification (./mvnw -pl foundation -am verify: 232 tests, Checkstyle and coverage gates met, including the Docker MySQL and PostgreSQL suites). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: James Maes <james@kof22.com>	2026-11-06 08:59:39 -06:00
james.maesandClaude Sonnet 5.5	d7199d385e	fix: keep the literal revision tag out of the root POM comment ... The shared Maven workflow reads the version with grep -m1 on the revision element, so a comment mentioning the element made it parse prose as the version and fail every publish run. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-06 08:21:46 -06:00
james.maesandClaude Opus 5.5	79c5b5453f	ci: use shared ci-workflows Maven workflow ... Replace the platform-ci release callers with one caller of KofTwentyTwo/ci-workflows maven.yaml (qqq-orb port). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-05 23:15:23 +00:00
james.maesandClaude Sonnet 5.5	8351fd7fb4	build: make the reactor root the single version source of every module ... The release pipeline rewrites <revision> only in the ROOT pom.xml (the pinned legacy calculate_version.sh) and nothing passes -Drevision (java-verify runs plain `mvn verify`), but every module declared its own <revision>0.1.0-SNAPSHOT</revision> and did not inherit the root. After an RC rewrite the root would say the RC while the modules still built as the SNAPSHOT, so capture (target/<artifact>-<root version>.jar) would find no JAR and the publisher (one version per reactor) would reject the reactor. The root now inherits qbit-build-parent 2.1.1 (foundation's existing parent) and every module inherits the root with the per-module <revision> removed (relativePath ../pom.xml, ../../pom.xml, ../../../pom.xml; remote-renderer transport and adapter keep inheriting remote-renderer-parent). GAVs, module list, dependencies, sources and tests are unchanged. Audited with `help:effective-pom` (Maven 3.9.11, before/after for all 11 projects): - licenses: root, foundation (Apache-2.0) unchanged; bridges/scripting previously inherited AGPL-3.0 from build-parent 2.0.0 and now states it explicitly (build parent 2.0.0 -> 2.1.1 for this module); the vendored OpenHTML module keeps its explicit LGPL-2.1+ entry (a child's <licenses> replaces the parent's); the seven modules that had no license (renderer, bridges/renderer, record-files, printing, remote-renderer parent/transport/adapter) now inherit the root's Apache-2.0, matching the repository LICENSE. - compiler: build-parent adds <source>21</source><target>21</target> to the compiler plugin; identical to the modules' maven.compiler.release 21; the Java 8 vendor module pins <source>8</source><target>8</target> explicitly next to maven.compiler.release 8 (testRelease 21 unchanged). - dependency management: build-parent imports qqq-bom-pom 4.0.0 (jackson 2.21.5, qqq 4.0.0, ...) which the parentless modules never had. record-files and printing now import qqq-bom-pom ${qqq.version} (as foundation and bridges/scripting already do), so their managed versions equal what qqq-backend-core RC.21 declares; renderer, bridges/renderer and remote-renderer-parent import jackson-bom 2.22.4 so jackson-core/annotations stay aligned with their explicit jackson-databind 2.22.4. - guardrails: build-parent 2.1.1 adds the qbit-guardrails test dependency, surefire dependenciesToScan and enforcer executions. foundation keeps them (enforcer.skip false); the other modules keep the previous behavior (enforcer.skip true, dependenciesToScan reset); the extra test-scope qbit-guardrails dependency and the snapshots-only central-portal-snapshots repository are inherited metadata. - url/scm: the root states build-parent's url/scm so the modules' derived metadata stays the same. The vendor's complete-source ZIP now ships parent/pom.xml (a copy of the reactor POM; module/pom.xml differs from the repository POM only in its relativePath, ../parent/pom.xml inside the archive), inputs.sha256 and the verify/build scripts follow, the README documents it, and renderer/Dockerfile copies the reactor POM from a named BuildKit context. Not built or tested: model introspection only. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-05 17:10:19 -06:00