Scheduled tasks — context_from chaining (seed from a specified prior fire)
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 152
- Forks
- 16
- Avg merge
- 14h 48m
- Merged PRs (30d)
- 536
Description
Summary
Add context_from: <fireID> to ScheduleSpec (or a fire-time override) so a fire can seed from a SPECIFIED prior fire's session instead of the immediate prior (LastFireSessionID). The Hermes Agent pattern.
Part of #189 (scheduled tasks). Split out of #236 (deferred/v2) — depends on the carried-context toggle landed in #256.
Scope
- A
ContextFrom stringfield onScheduleSpec(empty = useLastFireSessionID, the #256 default; non-empty = load the specified fire's session instead). - The fire path loads the specified fire's session by id and renders it as a fenced untrusted preamble, reusing #256's
renderCarriedContexthelper. Fencing discipline unchanged — the specified fire's context is equally untrusted. - Cross-schedule chaining: the specified fire may belong to a DIFFERENT schedule. Its session is loaded by id, no schedule join.
ContextFrom+OneShotRetryinteraction: same asCarryContext— a re-armed one-shot does NOT carry context on the retry.
References
- Design: #189, ADR 0059.
- The v2 finish: #256 (landed
CarryContext+ the fenced-preamble rendering this builds on).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the ScheduleSpec definition and the scheduled-task fire path, then read the CarryContext implementation and renderCarriedContext helper from #256. Trace how fire sessions are loaded, including retry handling, and consult ADR 0059 and #189 for the intended chaining behavior. Done means ContextFrom selects a session by ID across schedules while preserving fenced rendering and OneShotRetry semantics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100