fix: normalize zero-duration lifetime to workflow instead of immediate expiry

[stack72]

Summary

• Zero-duration strings like "0h", "0d", "00w" passed LifetimeSchema validation but produced 0ms when parsed by parseDuration(), causing data to expire immediately on creation. GC would then delete it on the next scan.
• Instead of rejecting zero-duration values (which could break existing on-disk data loaded via fromData()), we normalize them to "workflow" lifetime at the Data entity boundary. This means the data lives for the duration of the workflow run — a sensible default that prevents silent data loss.
• GarbageCollectionSchema now rejects zero-duration strings via .refine() (a GC policy of "0d" is nonsensical). The refine approach preserves acceptance of leading-zero non-zero values like "01d", staying consistent with LifetimeSchema.

Rationale: why normalize to "workflow" instead of rejecting?

Rejecting zero-duration values in both create() and fromData() would be simpler, but it would break any repo that already has data on disk with lifetime: "0h" — fromData() would throw a ZodError when loading it. Normalizing handles this gracefully: existing data loads correctly, and the "workflow" semantic is the safest fallback since it ties data lifecycle to something concrete (the workflow run) rather than deleting it immediately.

Lifetime + GC interaction (answering @adamhjk's question)

if I have a workflow lifetime and a gc of 1, what do we expect to happen?

Lifetime and garbage collection are orthogonal mechanisms:

• Lifetime controls when data expires. "workflow" lifetime means the data expires when the associated workflow run is deleted (checked via isExpired() → workflowRunRepo.findById()). It does not use time-based expiration — calculateExpiration("workflow", ...) returns null.
• GC controls how many versions are retained on disk. gc: 1 means only the 1 most recent version is kept; older versions are hard-deleted.

With lifetime: "workflow" and gc: 1:

1. While the workflow runs: Data is accessible. Multiple writes create new versions, but GC prunes to only the latest 1 version.
2. After the workflow run is deleted: isExpired() returns true → the "latest" symlink is removed (soft delete, data becomes inaccessible). Then GC hard-deletes old versions, leaving at most 1 version on disk.

No conflict — they compose naturally.

Changes

File	Change
src/domain/data/data_metadata.ts	Add normalizeLifetime() helper; add .refine() to GarbageCollectionSchema rejecting zero-duration strings
src/domain/data/data.ts	Call normalizeLifetime() in Data.create() and Data.fromData() before Zod validation
src/domain/data/data_metadata_test.ts	New file — 42 tests for normalizeLifetime() and GarbageCollectionSchema
src/domain/data/data_test.ts	11 new tests for zero-duration normalization through Data.create(), Data.fromData(), and roundtrip
src/domain/data/data_lifecycle_service_test.ts	6 new tests verifying zero-duration data gets null expiration (same as "workflow")

Test plan

• All 95 tests in the 3 modified/new test files pass
• Full test suite passes (1997 tests, 0 failures)
• deno check passes
• deno lint passes
• deno fmt passes

Closes #338

🤖 Generated with Claude Code

[github-actions]

Review Summary

This PR correctly fixes issue #338 where zero-duration lifetime strings like "0h", "0d", "00w" would cause data to expire immediately on creation. The approach of normalizing zero-duration values to "workflow" lifetime at the entity boundary is well-reasoned and handles backward compatibility gracefully.

Blocking Issues

None - This PR is ready to merge.

Code Quality Assessment

TypeScript & Code Style ✅

• No any types used
• All exports are named exports
• AGPLv3 header present in new test file
• Code passes lint, type check, and formatting (CI green)

Domain-Driven Design ✅

• Correct boundary placement: Normalization happens at the Data entity boundary (create() and fromData()), which is the right place for domain validation/transformation
• Pure function: normalizeLifetime() is a stateless helper that can be reasoned about in isolation
• Domain semantic choice: Converting zero-duration to "workflow" is a sensible domain decision that ties data lifecycle to something concrete rather than causing silent data loss

Test Coverage ✅

Comprehensive testing across 3 files (~59 new tests):

• data_metadata_test.ts (new): 42 tests for normalizeLifetime() and GarbageCollectionSchema
• data_test.ts: 11 tests for normalization through Data.create(), Data.fromData(), and roundtrip
• data_lifecycle_service_test.ts: 6 tests verifying zero-duration data gets null expiration

Test coverage includes edge cases:

• Zero with single digit (0h, 0d)
• Leading zeros that equal zero (00d, 000h)
• Leading zeros on non-zero values (01d, 007h) - correctly pass through
• Special lifetime values (ephemeral, workflow, etc.) - unchanged

Security ✅

• No injection vulnerabilities
• Regex is bounded (no ReDoS risk)
• No direct user input execution

Implementation Details ✅

• Regex in normalizeLifetime() matches LifetimeSchema pattern
• GarbageCollectionSchema correctly rejects zero-duration via .refine() (a GC policy of "0d" is nonsensical)
• Different treatment for LifetimeSchema (normalize) vs GarbageCollectionSchema (reject) is appropriate given the different semantics

Suggestions (Non-blocking)

None - the implementation is clean and focused. The PR description is also excellent with clear rationale for design decisions.

---

LGTM! 🎉