docs(deploy-to-cloud-engine): add service:git:updated_at (commit date) to version metadata

[artkorotkikh-dfinity]

Motivation

The console wants to show a last-updated field for a deployed app, but pitfall 16 bans build timestamps in wasm metadata (a $(date) value changes every build and breaks reproducibility). The last commit's date is the deterministic middle ground: it is a property of the source tree, not of the build, so rebuilding the same commit produces the same wasm.

Changes

• Added service:git:updated_at = $(git log -1 --format=%cI) to the version metadata example (git projects only).
• Verified by live builds (motoko recipe v5.0.0, icp-cli 1.0.2): the ISO 8601 value bakes correctly and is identical across rebuilds of the same commit.
• Reworded pitfall 16 to distinguish the banned build timestamp from the allowed commit date, and named the new field as the deterministic alternative.
• Clarified in the notes that the commit date means "code last changed", not deploy time — deploy time stays with the canister history the network records.
• Updated eval 15's expected behaviors to cover the new field and re-ran it.

Eval results

Output eval 15 — Adversarial: timestamp in wasm version metadata (updated case: WITH 4/4)

  WITH skill: 4/4 passed
    ✅ Refuses the build timestamp ($(date)-style) and offers service:git:updated_at / notes deploy time is in canister history
    ✅ Uses a metadata list under recipe configuration with standard names service:git:sha, service:git:origin, service:git:updated_at, service:version
    ✅ Uses command substitution for git values with a +dirty marker rather than hardcoded literals
    ✅ Does NOT invent differently named metadata entries as a compromise

The without-skill baseline for this run hit the runner's 120s timeout before producing output. The last completed baseline of this case (in #246) failed 0/4 with real output — it complied with the build timestamp via a predeploy script and invented build_timestamp / git_commit names — and that output also fails all four updated behaviors, so the with/without delta carries over.

🤖 Generated with Claude Code

[github-actions]

Skill Validation Report

Validating skill: /home/runner/work/icskills/icskills/skills/deploy-to-cloud-engine

Structure

• Pass: SKILL.md found

Frontmatter

• Pass: name: "deploy-to-cloud-engine" (valid)
• Pass: description: (1021 chars)
• Pass: license: "Apache-2.0"
• Pass: compatibility: (211 chars)
• Pass: metadata: (2 entries)

Tokens

• Warning: SKILL.md body is 7710 tokens (spec recommends < 5000)

Markdown

• Pass: no unclosed code fences found

Tokens

File	Tokens
SKILL.md body	7,710
Total	7,710

Content Analysis

Metric	Value
Word count	4,989
Code block ratio	0.09
Imperative ratio	0.13
Information density	0.11
Instruction specificity	0.96
Sections	18
List items	89
Code blocks	16

Contamination Analysis

Metric	Value
Contamination level	low
Contamination score	0.09
Primary language category	shell
Scope breadth	3

• Warning: Language mismatch: config (1 category differ from primary)

Result: 1 warning

Project Checks

✓ Project checks passed for 1 skills (0 warnings)

[marc0olo]

Approving. The determinism premise is verified by a live v5.0.0 build (commit date is a property of the commit, identical across rebuilds), the pitfall 16 rewrite is accurate, and the eval reasoning is legitimate — same prompt, so re-scoring the prior real 0/4 baseline from #246 against the updated behaviors holds; 120s baseline timeout disclosed. CI green.

Non-blocking note: service:git:updated_at is introduced under the "agreed convention the console will read" claim, but per the commit message the name is a local naming decision rather than a confirmed console spec. Since the skill's own note warns that differently-named entries won't be picked up and this field is baked into every deploy by default, worth a quick confirmation with whoever owns the console service:* convention that updated_at is the exact name — not a merge blocker. LGTM.