Define reliability, observability, and recovery behavior #42
Labels
No labels
ready-for-agent
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
#43 Choose the application architecture and technology stack
caleb-brown/temper
#32 Define the supported production deployment envelope
caleb-brown/temper
#35 Define revision, trigger, deduplication, retry, and stale-run semantics
caleb-brown/temper
#36 Define review-context assembly and model-execution policy
caleb-brown/temper
#38 Define repository onboarding and connection lifecycle
caleb-brown/temper
Reference
caleb-brown/temper#42
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Parent
#29 — Temper v1 Greenfield Product and Architecture
Question
How should Temper behave across crashes, duplicate and out-of-order deliveries, queue pressure, leases, cancellation, timeouts, retries, rate limits, ambiguous Forgejo writes, stale revisions, provider failures, and dependency outages; and which health checks, logs, metrics, alerts, diagnostic details, and operator recovery actions make those states safe and understandable?
Blocked by