An EPUB publication date is not automatically the file creation time or the latest modification timestamp. For EPUB date metadata, keep the intended publication date, export timestamp, and dcterms:modified in separate fields. Their labels matter even when calendar values happen to match.
The saved date and generated OPF did not agree
The controlled volume command set and read back 2026-12-17 as the publication date. Yet the deterministically generated EPUB contained 2026-09-03T09:00:00+09:00 in dc:date. This means the workspace setting response and the packaged metadata require independent acceptance; the current artifact does not prove that the requested publication date reached OPF.
Calling this configuration complete would misstate the evidence. Recovery should first confirm the stored wizard value, then isolate which date source the exporter writes. Do not substitute the export timestamp merely because the package remains structurally valid.
The EPUB itself passed local inspection with four images, eight spine entries, and both navigation formats. Structural validity does not cure the date mismatch. Accept the metadata only when the intended date and its semantic role are visible in the reopened OPF; until then, the date-specific result remains unverified.
A controlled one-field comparison
Create a second package with only the date advanced by one day. Compare every packaged file and inspect only the files whose hashes changed. A discovered value must still be classified as publication date rather than modification time. Until that role is established, keep the OPF result explicitly unresolved.
Keeping the unresolved field visible at handoff
Mark the candidate file as date-unverified and retain its hash. A later two-date comparison can identify the changed package resource without confusing publication date with build time. Remove the hold only after the exact field and its semantic role are documented for the same EPUB.
Start with the calendar-invalid input
The synthetic run passed 2026-02-30 to the volume-setting command in dry-run mode. It returned exit code zero even though February 30 is not a real calendar date. A successful response therefore proves only that the value passed the command path used here. It does not validate the calendar. Recovery began by replacing it with the real date 2026-08-17 before any release artifact was accepted.
Read the corrected value from volume state
The corrected date and version 1.0 were saved for volume zero. A separate volume-list call returned 2026-08-17, establishing that the workspace state retained the intended value. The graphical date picker on wizard page five was not rendered by the CLI, so its selection highlight and button behavior remain unobserved. The saved state, not a remembered screen, is the evidence for this step.
Export at a fixed, different timestamp
The one-chapter English specimen was exported deterministically with fixed time 2026-09-03T09:00:00+09:00. Choosing an export time different from the publication date makes the two meanings distinguishable. Rune reopened the resulting EPUB as locally valid. Its digest is 91297a1573aa1efe42e9a5e237b97b381c8b88fdd5d6a40c6503c382236ac96b.
Find the publication date in the colophon
The extracted OEBPS/Text/colophon.xhtml contains the line August 17, 2026 eBook ver 1.0 published. This is direct evidence that the corrected page-five value reached the generated reader-facing colophon. It is not evidence about every metadata node elsewhere in the package, so the OPF needs a separate inspection.
Read the OPF date without assuming its meaning
OEBPS/content.opf contains <dc:date>2026-09-03T09:00:00+09:00</dc:date>. No OPF file contained the exact selected date 2026-08-17. In Rune 1.4.0 build 23, this measured export therefore uses the fixed export timestamp for that node rather than the chosen publication date. The finding resolves the earlier ambiguity by showing a mismatch, not by pretending the requested value was carried.
Decide acceptance from the recipient's requirement
If the goal is to print the publication date in Rune's colophon, page five plus state reread and colophon inspection provides a repeatable route. If a distributor requires dc:date to equal the publication date, this package is not complete under that rule. Use a specified metadata correction path or wait for a product change, then inspect the new OPF again. Do not label the export valid for that requirement merely because the general container check passed.
EPUB publication date metadata must be discussed as at least two outputs: the reader-facing colophon and the package's dc:date. This specimen proves where each value came from, records the invalid-date weakness, and keeps the unobserved UI boundary explicit. That is a safer handoff than saying simply that a date was entered.
A release record should therefore contain separate fields for requested ISO publication date, calendar validation, saved volume value, rendered colophon text, OPF dc:date, and export timestamp. In this specimen those fields visibly contain two different dates. Collapsing them into a single note saying “EPUB date set” would lose the exact fact a distributor may care about.
The invalid-date result also suggests a practical guard for automation. Validate year, month, and day with a calendar-aware routine before invoking the Rune setting command, then read the stored value back. Format validation alone is insufficient because 2026-02-30 has the expected shape. Preserve the rejected input in evidence, but do not persist it to the release workspace.
If a future Rune build changes OPF behavior, repeat the same fixed-time test rather than editing this result. Use a publication date and export timestamp that cannot be confused, inspect both colophon and OPF, and identify the binary version. A new successful result can then supersede the limitation for that version without rewriting what build 23 actually produced.
This approach also prevents a broad metadata fix from becoming an undocumented package patch. Any post-export change to content.opf must follow the recipient's specification, preserve EPUB validity, update modification metadata correctly, and create a new digest. Until such a path is validated, the honest status for an OPF-publication-date requirement is unresolved, even though the colophon date is correct.