8 Commits

Include renames

Author	SHA1	Message	Date
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.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.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 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
James MaesandClaude Sonnet 5.5	4078f39688	docs: describe the vendored OpenHTML artifact at the family version in its modification notice ... QQQ-MODIFICATIONS.txt (shipped in the jar's META-INF) still named the artifact 1.1.105-qqq-p1. The module is now published at the QBit Document Generation family version, so the notice states that the modified library is upstream 1.1.105 with QQQ patch level 1 (originally distributed as 1.1.105-qqq-p1) and points at the openhtml.* POM properties. The LGPL modification statement is otherwise unchanged. The hash-pinned complete-source archive carries the same file bytes and inputs.sha256 is updated. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-05 17:10:19 -06:00
James MaesandClaude Sonnet 5.5	ab3f357599	build: publish the vendored OpenHTML module at the family version and flatten the reactor root ... The qrun publisher declares one version per reactor and the capture step looks for target/<artifact>-<root version>.jar, so the vendored OpenHTML module (own version 1.1.105-qqq-p1) could not be published with the family. Keep the GAV group and artifact (com.kingsrook.thirdparty:openhtmltopdf-pdfbox), make its version the family ${revision} (default 0.1.0-SNAPSHOT, like the other modules), flatten its consumer POM, and point renderer at ${revision}. Java sources and renderer behaviour are unchanged. The module keeps its explicit LGPL-2.1-or-later license and records upstream provenance (tag 1.1.105, commit 54b31598, patch level p1, upstream project URL and scm) in properties, url and scm; it does not inherit the Apache license of the reactor. The hash-pinned complete-source archive is regenerated with the same module/pom.xml (inputs.sha256 updated; module/pom.xml is again identical to the module pom) and build-openhtml.sh derives the artifact names from the module revision. The reactor root is itself a pom-packaging module the publisher checks, so it gets the flatten plugin (otherwise ${revision} stays unresolved). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-11-05 17:10:18 -06:00
3 people	ee782b7d6e	chore: preserve unfinished document generation source and status ... Checkpoint implementation at user-requested stop; document known failures and incomplete release qualification. Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: GPT-6 Codex <noreply@openai.com>	2026-11-04 10:45:09 -06:00