Module jobs_apply 

jobs.apply: an author’s declared jobs reach a harness through the harness’s own verbs (docs/architecture/content-spec-status.md).

A spec is a set of JobSpecs keyed by name. apply reads what the harness has in the one store the request addresses (the root home, or the named profile’s), keyed by each job’s native name, then runs the controlled-tier verbs in crate::jobs_control: create for a name the store lacks, update with only the declared fields that differ for a name it has. It writes no harness file; every outcome is a verb’s own re-read row.

What apply never does:

• delete — a job the spec does not name (the agent’s, an operator’s, one with no name) stays, and is reported as unnamed;
• guess — a declared name two existing jobs share is refused;
• override an operator — enabled is the value at creation; a job whose state differs from the spec is reported as drift, never paused or resumed;
• declare a one-shot — a once schedule is an act, not a standing declaration, and is refused.

Declared values are normalized the way Hermes stores them (skills trimmed and de-duplicated in order, model and provider trimmed, ~ expanded and paths canonical in workdir), so a spec that already holds is unchanged on every re-apply. A value Hermes would store differently in a way that cannot be normalized is refused, never re-edited forever.

Structs

AppliedJob

A job named in an apply report.

JobSpec

One declared job: what the author wants to exist, never what the harness has made of it.

JobsApply

One jobs.apply request.

JobsApplyOutcome

What one jobs.apply did, every outcome the harness’s own answer.

Functions

apply

Apply a declared job set through the harness’s own verbs.