4 Commits

Include renames

Author	SHA1	Message	Date
james.maesandClaude Fable 5.2	bf546e16c5	feat(bridge): accept renderer 0.2.0, read its diagnostics, preview a label (P5) ... On develop the renderer speaks qqq-renderer-0.2.0 and the bridge accepted only 0.1.0, so the bridge refused its own renderer, a label could not be previewed, and a render target was accepted and then ignored. The version rule (RendererVersion). The bridge accepts 0.1.0 (the released fields, the 13 released refusals) and 0.2.0 (the same with diagnostics and detail, those refusals and the 15 scene refusals); any other version is rejected. Each set is written out, replacing the temporary enum range. A job is framed as 0.1.0 reads it unless it needs more. Before a job only 0.2.0 can do (a version 2 scene, a preview) the bridge asks the worker its version by validating a fixed, empty version 1 scene, so an old image is refused as RENDERER_TOO_OLD and receives nothing of the scene or the record; an answer from 0.1.0 to such a job is refused whatever it says. Diagnostics (WorkerAnswer, SceneFacts). A version 2 refusal is RenderException(code, diagnostic). The worker is untrusted, so every field is checked again: the closed vocabulary, whole numbers in bounds, an element only if the scene that was sent declares it, and a pointer only of array indexes, schema property names and declared ids. An answer holds at most 2048 diagnostics in one megabyte beside its label, and no frame passes the frame of the largest document the deployment admits. A refused answer that carries any part of a label is rejected. Render target. targetDpi is sent with a version 2 scene and the label is held by the output policy to the page at that resolution. A version 1 scene or a PDF asked for another resolution than its stock's is refused as TARGET_REQUIRES_SCENE_2 before any worker is contacted, because renderer 0.1.0 does not read the field. supportsRenderTarget() is true. Preview. preview() is the print path stopped before retention: the same job with collected diagnostics, the same integrity checks and output policy, and a page decoded by ZplRaster from the accepted label bytes. ZplRaster is its own strict reader of the policy's grammar and runs the policy first; it paints ^GFA and ^GB exactly, hatches printer font text (the page is then not exact) and writes a one-bit PNG itself. Refusals come back as diagnostics, never as a label. A refused scene is drawn on the host from the diagnostics' boxes alone: the worker sends no label for it and the wire gains no field for the partial canvas, so no host can print a label with elements missing. The design records the decision in sections 6.1 and B.1, the version question in 11.3 and what the host now reads from a scene in 8.1. renderer/qualification.json said qqq-renderer-0.1.0 and qqq-barcodes-1; it now says what the worker reports, and a test holds it to the answer. The mutation campaign covers the page decoder and the answer frames. The new classes are gated at 100% line coverage and the bundle gate rises to the measured 90% of instructions and 88% of lines. The version 1 corpus is untouched. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>	2026-11-12 12:02:54 -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	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
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