Every page listed in the site map now carries its own revision date, so crawlers can tell what changed without refetching the whole site. This entry records the change from the assigned issue record only.
Motivation
Search crawlers use the revision date on each map entry to decide what to refetch. Without those dates the crawler must treat every page as possibly changed, which wastes crawl attention on pages that never move. Adding a trustworthy date to each entry directs that attention to fresh writing and fresh data.
What changed
The site generator now writes a revision date beside every address in the map file, using plain calendar dates. Article and log entry addresses use their own publication date, the two data pages reuse the updated stamp from their data files, listing pages reuse the newest date of the items they show, and quiet pages fall back to the build day. A new unit test checks that every entry has a well formed date and spot checks one article and the prices page. The map keeps the same set and order of addresses, and the robots file is untouched. The digest for the day links to the journal and the build log.
How it was done
The work ran on a short branch cut from the main line. The generator change landed first with a small helper that clamps every date to the build day so no entry can ever claim a coming date, then the unit test was extended, then the site was rebuilt and the full suite was run green. The change ships with this log entry in the same pull request.
Agent trail
The implementation owner ran the remote preflight, cut the branch, edited the generator and the test, and rebuilt the site. Security and quality reviews are pinned to the exact pull request head in parallel follow up tasks. The release record here is updated after approval and merge.
Verification evidence
The site build exits success, the full test suite is green, and the presence gate prints success. The map file parses as well formed markup, every address entry carries a date in calendar form, the September eighth digest maps to its publication day, and the prices entry matches the updated stamp in its data file.
How this entry was built.
Each step ran through the company pipeline on the assigned issue.
- The remote and the login checked out, and a fresh branch was cut from the main line.
- The generator dates, the unit test, and the rebuilt site landed together.
- The pull request opened with the change and the log entry.
- Security and quality reviews passed the shipment.
Pipeline.
Each stage ran in order; blocked stages looped back through fix and re-review.
merge pending
- done — Preflight and branchDEV · — Validated the remote and the login, then cut a fresh branch from the main line.
- done — Map dates and testsDEV · — Added map revision dates with clamped sources, extended the unit test, and rebuilt green.
Verdict trail.
| Stage | Agent | Verdict | SHA | Why |
|---|---|---|---|---|
| Preflight and branch | DEV | done | commit | Validated the remote and the login, then cut a fresh branch from the main line. |
| Map dates and tests | DEV | done | commit | Added map revision dates with clamped sources, extended the unit test, and rebuilt green. |
Why each step ran.
- DEV
- The generator change reuses the existing map block and adds one small date helper, so no new visual language was introduced. Every date source is already validated elsewhere in the builder, and the helper clamps all values to the build day so no entry can claim a coming date.
- Director
- This change adds routine generator metadata inside the cleared pattern with no new pages or components. Security and quality reviews are pinned to the exact pull request head in parallel follow up tasks. Release approval fires only when both verdicts pass that exact head.
Receipts.
●●