@pikaa-ai/pikaa 0.2.5 → 0.3.1

package/skills/pptx-posters/references/manifest_spec.md

@@ -0,0 +1,297 @@
+# Poster manifest 2.0
+
+## Purpose
+
+The manifest is the only content input to the generator. It binds:
+
+- approved text and images;
+- exact source IDs;
+- local asset hashes and licenses;
+- PowerPoint canvas and physical output geometry;
+- conference and printer rules;
+- accessibility/quality thresholds and their basis;
+- reading order;
+- author approval to a canonical content hash.
+
+Unknown keys, duplicate JSON keys, non-finite numbers, remote asset paths, path escape,
+unapproved fields, unresolved sources, unused records, and common placeholders are
+rejected.
+
+## Template
+
+`assets/poster_manifest_template.json` is intentionally invalid. It contains
+replacement tokens, false confirmations, and draft approval so it cannot produce a
+poster accidentally.
+
+Copy it into a project directory, then replace every field with reviewed values.
+Asset paths are relative to that manifest's directory.
+
+## Top-level object
+
+Manifest version 2.0 requires exactly these keys:
+
+- `schema_version`
+- `document`
+- `canvas`
+- `physical_output`
+- `requirements`
+- `quality`
+- `palette`
+- `sources`
+- `assets`
+- `elements`
+- `approval`
+
+The validator rejects extensions to the schema rather than silently ignoring them.
+
+## `document`
+
+- `id`: stable identifier beginning with a letter.
+- `title`: exact approved title.
+- `subject`: exact approved description for core document metadata.
+- `language`: BCP 47-style language tag.
+- `authors`: exact ordered author names.
+- `source_ids`: exact records supporting title, subject, language, and author metadata.
+
+Exactly one text element with role `title` must match `document.title` verbatim.
+It must have `reading_order: 1`; generation uses it as the native PowerPoint slide
+title placeholder rather than as an undifferentiated text box.
+
+## `canvas`
+
+- `width_in`, `height_in`: PowerPoint slide dimensions, each 1–56 inches.
+- `background_color`: opaque six-digit sRGB hex.
+
+These are design dimensions, not automatically the physical trim size.
+
+## `physical_output`
+
+- `trim_width_in`, `trim_height_in`: finished physical dimensions.
+- `bleed_in`: physical bleed on each edge.
+- `safe_margin_in`: inset inside the trim edge for non-bleed content.
+- `orientation`: `portrait`, `landscape`, or `square`, matching trim dimensions.
+
+The physical artboard is trim plus twice the bleed. It must share the canvas aspect
+ratio.
+
+## `requirements`
+
+### `conference`
+
+The organizer record must be confirmed and provide:
+
+- exact `source_id`;
+- maximum width and height;
+- orientation (`portrait`, `landscape`, `square`, or `either`);
+- required delivery format (`PDF`, `PPTX`, `PDF_AND_PPTX`, or `OTHER`);
+- notes copied or summarized from the verified rule.
+
+The physical trim dimensions must fit.
+The referenced source record must have kind `conference_rule`.
+
+### `printer`
+
+The printer record must be confirmed and provide:
+
+- exact `source_id`;
+- trim width/height, bleed, and safe margin matching `physical_output`;
+- accepted color mode (`RGB`, `CMYK`, or `PRINTER_MANAGED`);
+- whether uniform scaling is allowed;
+- notes describing the confirmed workflow.
+
+If scaling is forbidden, canvas and physical artboard must be 1:1. A CMYK requirement
+does not prevent creation of an editable RGB PPTX, but the export plan blocks a claim
+of print readiness pending printer-approved conversion/proof.
+The referenced source record must have kind `printer_rule`.
+
+## `quality`
+
+- `minimum_font_pt_final`
+- `font_guidance_basis`
+- `font_guidance_source_id`
+- `minimum_raster_dpi_final`
+- `raster_dpi_basis`
+- `raster_dpi_source_id`
+
+Basis values are:
+
+- `heuristic`
+- `source_specific`
+- `conference_requirement`
+- `printer_requirement`
+
+A heuristic must have a null source ID. Every other basis requires an exact source
+ID. Values apply at final physical output, after uniform scaling.
+
+## `palette`
+
+`colors` maps stable IDs to opaque `#RRGGBB` sRGB values.
+
+Each `contrast_pairs` record contains:
+
+- `id`
+- `foreground_color_id`
+- `background_color_id`
+- `usage`: `normal_text`, `large_text`, or `non_text`
+
+The validator applies 4.5:1 to normal text and 3:1 to large text/non-text. A text
+element using `large_text` must be at least 18 pt final, or at least 14 pt final and
+bold.
+
+`data_series_redundant_encoding` must be true. This is an author confirmation that
+color is supplemented by labels, shapes, markers, patterns, or line styles. It is not
+an automated certification.
+
+## `sources`
+
+Each source has:
+
+- `id`
+- `kind`
+- `citation`
+- `locator`
+- `author_verified: true`
+
+Kinds include author content, publication, dataset, asset license, conference rule,
+printer rule, institutional rule, and other.
+
+Every source must be used, and every referenced ID must exist. The scripts do not
+resolve URLs, DOIs, or local records.
+
+## `assets`
+
+The array may be empty: figures, logos, and QR codes are optional. Only local
+PNG/JPEG assets are accepted when an asset is present. Each record has:
+
+- `id`
+- manifest-relative `path`
+- `role`: `figure`, `logo`, or `qr_code`
+- lowercase SHA-256
+- exact `source_id`
+- `license`: exact license or permission statement
+- `provenance`: exact author-verified origin or generation record
+- concise `alt_text`
+- `author_approved: true`
+- `qr_target`
+
+`qr_target` is null except for QR assets, where it is an exact `https://` URL. Files
+are bounded, final symlinks are rejected, paths cannot escape the manifest directory,
+and hashes must match.
+
+All asset records must be placed in the poster.
+Use one asset record for repeated placement of the same file; duplicate asset paths
+are rejected.
+
+The image inventory rejects EXIF, XMP, comments, and embedded text/application
+metadata to avoid publishing hidden or location-identifying information. Flatten and
+strip such metadata in an author-reviewed offline workflow, then hash and approve the
+resulting pixels as a new asset. ICC profiles and basic technical image fields are
+reported but not silently removed.
+
+## `elements`
+
+Elements are listed in ascending, contiguous `reading_order` from 1. The list order is
+not silently changed.
+
+Every element has:
+
+- `id`, `type`, and `reading_order`
+- design coordinates `x_in`, `y_in`, `width_in`, `height_in`
+- one or more exact `source_ids`
+- `author_approved: true`
+- `allow_in_bleed`
+
+All boxes must stay on the canvas. Non-bleed elements must remain inside the physical
+safe area mapped to the canvas. Text can never be allowed in bleed.
+
+### Text elements
+
+Text elements also specify:
+
+- `role`
+- exact `text`
+- `font_size_pt_design`
+- `font_face`
+- `bold`
+- horizontal and vertical alignment
+- `contrast_pair_id`
+- optional `line_color_id`
+- `line_width_pt`
+- `margin_in`
+
+Roles include title, authors, affiliation, heading, body, caption, reference,
+acknowledgement, contact, QR fallback, and other.
+
+Font size is checked after physical scaling. Text auto-shrink is disabled during
+generation.
+
+### Image elements
+
+Image elements also specify:
+
+- `asset_id`
+- `fit: "contain"`
+- `fallback_text_element_id`
+- `long_description_element_id`
+
+Contain fitting preserves aspect ratio and centers the image. A QR asset requires a
+square box and a fallback text element whose role is `qr_fallback` and whose text
+contains the exact `qr_target`. Other assets use null fallback IDs.
+
+`long_description_element_id` is null when approved alt text and adjacent native text
+are sufficient. For a complex figure that needs a longer explanation, it references
+an approved native text element with role `body`, `caption`, or `other`. That element
+must follow the image in reading order and include every source ID used by the image.
+QR assets use the required visible fallback text and therefore set this field to null.
+The reference is structural; a human must decide whether the description is complete.
+
+## Approval
+
+Draft form:
+
+```json
+{
+  "status": "draft",
+  "approved_by": null,
+  "approved_at": null,
+  "content_sha256": null
+}
+```
+
+After all non-approval fields validate:
+
+```bash
+python -B scripts/validate_manifest.py poster.json \
+  --print-content-hash
+```
+
+Give the exact manifest and reported hash to the author. Approved form requires:
+
+- `status: "approved"`
+- nonempty `approved_by`
+- ISO 8601 `approved_at` with UTC offset
+- exact lowercase `content_sha256`
+
+The hash covers every top-level field except `approval`, using canonical sorted
+UTF-8 JSON. Any content, source, requirement, palette, coordinate, or asset-metadata
+change invalidates approval.
+
+## Validation modes and exit codes
+
+Normal validation reads and hashes assets and requires approval:
+
+```bash
+python -B scripts/validate_manifest.py poster.json
+```
+
+`--structure-only` skips file reads/hashes but still validates path syntax. Use it for
+planning/audit only, never generation.
+
+`--print-content-hash` permits draft approval but does not permit placeholders,
+unverified sources, unapproved elements, or false requirements.
+
+CLIs use:
+
+- exit 0: pass;
+- exit 1: completed audit found a release-blocking issue;
+- exit 2: invalid input, unsafe input, missing dependency, or command error.

package/skills/pptx-posters/references/poster_content_guide.md

@@ -0,0 +1,176 @@
+# Source-bound poster content
+
+## Non-negotiable rule
+
+The generator renders approved manifest content. It does not research, infer, draft,
+summarize, complete, or "improve" scientific claims. Never invent poster text,
+citations, data, statistics, author details, affiliations, funding statements, image
+licenses, or QR destinations.
+
+If an exact source or author approval is missing, stop. Keep the manifest in `draft`
+status. Do not replace missing material with plausible prose.
+
+## Build an evidence packet first
+
+Ask the author for the local, authoritative material needed for this poster:
+
+- accepted abstract or author-approved summary;
+- exact title, author order, affiliations, contact details, and identifiers;
+- final tables, figures, captions, units, sample sizes, statistics, and uncertainty;
+- bibliography or exact publication identifiers;
+- funding, conflict, ethics, registration, data, and code statements where applicable;
+- optional local logos and images plus provenance and ownership/license/permission
+  records;
+- organizer poster instructions and printer specifications;
+- exact QR destination and the visible fallback URL/text.
+
+Record each item as a `sources[]` entry with a unique ID. A locator can be a DOI,
+stable URL, local controlled-record identifier, figure/table number, page/section,
+or dated author instruction. The scripts never dereference it.
+
+`author_verified: true` means a human author checked that source record. It does not
+mean an agent found a plausible web page.
+
+## Exact source IDs
+
+Every text or image element has `source_ids`. These IDs must exactly match records in
+`sources[]`; fuzzy title matching is forbidden.
+
+Use the smallest defensible source set:
+
+- a title/author element can cite the accepted-submission or author-roster record;
+- a result sentence should cite the exact table, figure, analysis output, or
+  publication location supporting it;
+- a figure should cite its data/figure provenance and its asset-license record;
+- a conference dimension should cite the organizer's current instruction;
+- a printer constraint should cite the current quote, specification, or written
+  confirmation.
+
+The validator rejects unknown and unused source IDs. This catches misspellings and
+stale records instead of guessing what the author meant.
+
+## Content selection is author-controlled
+
+There is no universal section list, word count, visual percentage, number of figures,
+or citation count. Use the organizer's requirements and the research story.
+
+A useful author review asks:
+
+1. What question should a viewer understand?
+2. Which exact result supports the take-home message?
+3. Which method detail is necessary to interpret that result?
+4. Which limitation prevents overstatement?
+5. What action or follow-up should the viewer take?
+
+Possible sections include context, objective, methods, results, limitations,
+conclusions, references, acknowledgments, and contact information. Include only those
+that are supported and appropriate. Clinical, qualitative, engineering, humanities,
+and computational posters often need different structures.
+
+## Preserve scientific meaning
+
+For each candidate edit:
+
+- preserve direction, magnitude, units, denominators, uncertainty, and qualifiers;
+- distinguish observed association from causation;
+- retain negative/null results when necessary to prevent a misleading summary;
+- keep population, intervention, comparator, endpoint, and time frame where relevant;
+- do not convert a model metric into a clinical or practical claim;
+- do not add significance language that the source does not support;
+- do not remove limitations that materially change interpretation;
+- define acronyms for the intended audience;
+- keep citation labels synchronized with the exact bibliography.
+
+An agent may propose shorter wording, but the author must approve the exact resulting
+text and renew the manifest content hash.
+
+## Figures and data
+
+Figures are optional. Use author-supplied local assets or assets generated separately
+from exact author data in a reviewed workflow. This skill makes no network or model
+calls. Do not create substitute data, redraw values from memory, or ask an image model
+to depict scientific results.
+
+Before approval, verify:
+
+- values, labels, units, error definitions, sample sizes, and statistical notation;
+- category order, axes, scales, transformations, baselines, and truncation;
+- correspondence between caption and plotted data;
+- direct labels or a clear legend;
+- redundant encoding beyond color;
+- asset hash, source ID, exact provenance, license/permission, and concise alt text;
+- a source-bound native long description when alt text and adjacent prose are
+  insufficient for a complex figure;
+- final effective DPI for raster assets.
+
+If a chart must be regenerated, regenerate it from the author's exact data using a
+separate, reviewed analysis workflow. Record the tool/version or controlled workflow,
+input source IDs, date, human reviewer, and permission to use the output. Then add the
+resulting local image and provenance to the manifest.
+
+## Citations and references
+
+Copy citations only from the author's verified bibliography or primary source record.
+Never fabricate missing metadata. Keep identifiers exact, including DOI capitalization
+and version/date where those distinguish records.
+
+Space pressure does not justify an ambiguous citation. If the organizer permits a
+short display form, keep a stable identifier and provide an exact accessible full-list
+destination. The visible poster still needs enough information for a viewer to
+identify the source without relying solely on a QR code.
+
+## QR codes
+
+A QR image is only a local asset. The scripts do not generate it, resolve it, follow
+it, or create a hyperlink.
+
+For every QR asset:
+
+- record one exact `https://` target in `asset.qr_target`;
+- provide a separate text element with role `qr_fallback`;
+- include that exact URL verbatim in the fallback text;
+- cite the same source record from the image and fallback text;
+- write alt text that states the QR code's purpose and destination;
+- test the exported and printed code manually on multiple devices.
+
+Do not use a QR code as the only way to access essential poster content.
+
+## Approval binding
+
+Approval is content-specific:
+
+1. Complete the manifest with local assets and all exact source IDs.
+2. Keep `approval.status` as `draft`.
+3. Run the validator with `--print-content-hash`.
+4. Give the exact manifest and reported hash to the approving author.
+5. After approval, set `status`, `approved_by`, `approved_at`, and
+   `content_sha256`.
+6. Run normal validation and generation.
+
+Any change outside `approval` changes the canonical hash. The validator then refuses
+generation until an author approves the new hash.
+
+## Placeholder policy
+
+The bundled template intentionally contains replacement tokens, false confirmations,
+and draft approval. It must fail validation.
+
+The validator rejects common placeholder forms such as TODO, TBD, Lorem ipsum,
+REPLACE_ME, generic bracketed fields, and unresolved template labels. Do not weaken
+this policy to make a draft generate. Replace every field with reviewed content or
+stop.
+
+## Final content review
+
+Before release, the presenting/corresponding author should compare the poster against
+the original evidence packet and check:
+
+- title, author order, affiliations, correspondence, and funding;
+- every claim, number, unit, citation, image, and caption;
+- methods and limitations needed for valid interpretation;
+- consistency between poster text and figures;
+- accessibility text, visible QR fallbacks, and meaningful contact information;
+- conference and printer compliance;
+- the final manifest hash and generated PPTX hash.
+
+An automated pass never substitutes for scientific sign-off.

package/skills/pptx-posters/references/poster_design_principles.md

@@ -0,0 +1,226 @@
+# Poster design and accessibility principles
+
+## Requirements outrank conventions
+
+There is no universal poster size, orientation, grid, body font, margin, image DPI,
+word count, or number of columns. Confirm the current organizer and printer rules,
+record exact source IDs, and design against those constraints.
+
+Use generic advice only as a labeled project heuristic. Do not transform a heuristic
+into a conference or accessibility requirement.
+
+## Visual hierarchy
+
+Make the research question, key result, and interpretation easy to locate without
+forcing every poster into one visual style.
+
+- Use a small, consistent set of text roles.
+- Prefer left-aligned body text for left-to-right languages unless language or design
+  requirements indicate otherwise.
+- Keep related evidence, caption, and interpretation spatially grouped.
+- Use spacing, alignment, size, and weight before adding decorative effects.
+- Avoid unexplained icons, dense backgrounds, and text over uncontrolled imagery.
+- Do not rely on a predicted "eye pattern"; confirm the actual reading order.
+
+The generated PPTX uses fixed font sizes and disables text auto-shrink. A visual check
+is still required because the XML package does not reveal font substitution or
+rendered overflow.
+
+## Font size means final-output size
+
+PowerPoint stores point sizes on the PPTX canvas. When the printer scales the canvas,
+the physical text scales too:
+
+`final point size = design point size × physical artboard width / canvas width`
+
+Use the same ratio on height; unequal ratios are prohibited.
+
+Microsoft's PowerPoint accessibility guidance recommends 18 pt or larger for ordinary
+slides. That is a [Microsoft slide recommendation](https://support.microsoft.com/en-us/office/make-your-powerpoint-presentations-accessible-to-people-with-disabilities-6f7772b2-2f33-4bd2-8ca7-dae3b2b3ef25),
+not a universal poster minimum. Poster viewing distance, typeface, substrate, lighting,
+audience, and organizer rules can require larger text.
+
+The manifest therefore requires:
+
+- a final-output minimum;
+- a basis labeled `heuristic`, `source_specific`,
+  `conference_requirement`, or `printer_requirement`;
+- an exact source ID for every non-heuristic basis.
+
+Test a reduced-scale print and the full-size proof under expected viewing conditions.
+
+## Font availability and substitution
+
+A typeface name in PresentationML is a request, not proof that the font is installed,
+licensed for embedding, or rendered identically by another workstation. Microsoft's
+[font-embedding guidance](https://support.microsoft.com/en-us/office/benefits-of-embedding-custom-fonts-cb3982aa-ea76-4323-b008-86670f222dbc)
+notes that embedding can preserve layout but that not every font permits it and that
+embedding only used characters limits editing.
+
+The generator does not install or embed fonts. Before release:
+
+- use fonts licensed for the intended authoring, sharing, embedding, and print use;
+- confirm every declared face is installed on the review/export workstation;
+- inspect substitutions, missing glyphs, equations, and line wrapping in PowerPoint;
+- decide with the printer whether embedding is appropriate and permitted;
+- inspect the actual exported PDF's font records and rendered glyphs.
+
+## Text contrast
+
+[WCAG 2.2 SC 1.4.3](https://www.w3.org/TR/WCAG22/#contrast-minimum) specifies:
+
+- 4.5:1 for normal text;
+- 3:1 for large text, defined as at least 18 pt, or at least 14 pt and bold.
+
+WCAG is written for web content. This skill uses its sRGB contrast mathematics and
+thresholds as an explicit design target for poster/PPTX color pairs; a passing ratio
+does not by itself establish that a physical poster or exported PDF conforms to WCAG.
+Print conversion, transparency, gradients, images behind text, paper, glare, and
+lighting require manual review and proofing.
+
+The manifest declares each foreground/background pair and its usage. Text elements
+must reference a declared pair. The validator rejects a pair below its declared
+threshold.
+
+## Non-text contrast and color redundancy
+
+[WCAG 2.2 SC 1.4.11](https://www.w3.org/TR/WCAG22/#non-text-contrast) uses 3:1
+against adjacent colors for graphical parts required to understand content.
+[SC 1.4.1](https://www.w3.org/TR/WCAG22/#use-of-color) says color must not be
+the only visual means of conveying information.
+
+For plots and diagrams:
+
+- directly label important series and regions when practical;
+- combine color with shape, marker, pattern, line style, position, or text;
+- retain meaningful distinctions in grayscale;
+- avoid assigning semantic meaning to a hue without another cue;
+- check the rendered figure, not just the palette's color list.
+
+The palette checker reports exact pair ratios and heuristic grayscale L* separation.
+It explicitly does not certify color-vision accessibility.
+
+## Choosing palettes
+
+[ColorBrewer](https://colorbrewer2.org/) separates qualitative, sequential, and
+diverging schemes and provides filters for colorblind-safe, print-friendly, and
+photocopy-safe options. Its palettes were designed for maps; use the data-type logic,
+then test the actual poster figure and background.
+
+[Paul Tol's colour-scheme technical note](https://sronpersonalpages.nl/~pault/data/colourschemes.pdf)
+provides schemes intended to remain clear for color-blind readers. Choose a scheme
+for its documented purpose and supported category count. Do not assume every color
+in a named scheme has sufficient text or line contrast against white.
+
+Palette provenance does not replace contrast checks, redundant encodings, color-vision
+simulation, or print proofing.
+
+## Alt text and native text
+
+Microsoft says visuals need concise alternative text describing their purpose and
+important content. See
+[Make PowerPoint presentations accessible](https://support.microsoft.com/en-us/office/make-your-powerpoint-presentations-accessible-to-people-with-disabilities-6f7772b2-2f33-4bd2-8ca7-dae3b2b3ef25).
+
+This generator requires approved alt text for every local picture and writes it to
+the standard PresentationML nonvisual drawing description. The technical inspector
+checks that the description exists. It also supports a source-bound native text
+element as a long description for a complex figure.
+
+Alt text still needs human review:
+
+- describe the purpose and essential conclusion, not every pixel;
+- avoid repeating adjacent text verbatim;
+- do not begin with redundant phrases such as "image of";
+- include essential values and relationships when they are not available in nearby
+  native text;
+- keep important words as native PowerPoint text rather than only inside a raster
+  image.
+
+When concise alt text and adjacent prose do not communicate a figure's essential
+relationships, values, uncertainty, and conclusion, set
+`long_description_element_id` to an approved native body/caption/other text element.
+It must follow the image in reading order and cite every source used by the image.
+The structural check cannot determine whether the long description is scientifically
+or semantically complete.
+
+An XML attribute being present does not prove that the description is accurate.
+
+## Reading order
+
+Screen readers use an object's reading order, which can differ from its visual
+position. Microsoft recommends the Accessibility Checker and Reading Order pane.
+
+The manifest requires the visible title first, then contiguous `reading_order` values.
+The generator uses a native title placeholder, adds remaining shapes in that order,
+and writes explicit language on text runs. This is only a deterministic starting
+point. In the final PowerPoint:
+
+1. run Review > Check Accessibility;
+2. inspect the Reading Order pane;
+3. verify every object name and sequence;
+4. navigate with a keyboard;
+5. test with a screen reader.
+
+Groups, charts, SmartArt, decorative objects, and exported PDF tags need separate
+manual review. The strict generator intentionally limits its shape set to native text
+boxes and local pictures.
+
+## QR codes and links
+
+A QR code is not an accessibility substitute.
+
+- Include the exact destination URL as visible native text.
+- Use meaningful surrounding language that describes the destination.
+- Add alt text to the QR image.
+- Keep the fallback text in logical reading order.
+- Test the final exported/printed code with multiple devices.
+- Do not put essential content only behind the QR destination.
+
+The generator does not create a clickable external relationship. This allows the
+package inspector to reject all external relationships consistently.
+
+## Raster quality
+
+File metadata DPI does not determine poster quality. Use effective DPI:
+
+`effective DPI = source pixels / final placed inches`
+
+Calculate it independently for width and height at the final physical output. The
+asset inventory reports the lower value. The threshold must be labeled as a heuristic
+or tied to the exact organizer/printer/source rule.
+
+PowerPoint can compress inserted pictures. Microsoft documents High fidelity and
+per-document "Do not compress images in file" settings. Review those settings in the
+actual export application, then inspect the PDF and proof for resampling; the source
+PPTX effective-DPI calculation does not prove export resolution.
+
+Vector artwork may be preferable for line art, but this strict generator accepts only
+bounded local PNG/JPEG assets. If vector content is required, convert it through an
+author-reviewed, offline workflow and verify the rasterized result and text
+accessibility; do not silently substitute or redraw scientific content.
+
+## Audio, video, and linked media
+
+PowerPoint supports audio and video, including formats and linked-file workflows that
+vary by version. None is needed for a static printed poster. The strict manifest and
+package profile therefore allow only local PNG/JPEG still images and reject audio,
+video, linked media, transitions, timing, and other interactive content. Put optional
+external material behind a visible, verified URL/QR fallback rather than embedding or
+linking media in the PPTX.
+
+## Manual accessibility gate
+
+Before release:
+
+- run PowerPoint's Accessibility Checker;
+- verify reading order and object names;
+- review every alt text and native long description;
+- test screen-reader and keyboard navigation;
+- inspect text contrast, non-text contrast, and redundant encoding;
+- review reduced-scale and full-size proofs;
+- verify exported PDF tags and reading order;
+- test visible fallback links and QR codes;
+- get author and accessibility-reviewer sign-off.
+
+Automation finds technical defects. It cannot certify accessibility or scientific
+accuracy.