| name | mainsequence-orchestration-and-releases |
| description | Use this skill when the task is about operational execution in a Main Sequence project. This skill owns jobs, schedules, batch scheduling files, project images, run inspection, project resources, releases, and Artifacts as operational inputs. It does not own DataNode producer design, SimpleTable schema design, API route contracts, or RBAC policy. |
Main Sequence Orchestration And Releases
Overview
Use this skill when the task is about getting project code to run on the platform in a controlled and verifiable way.
This skill is for:
- jobs
- schedules
- images
- project resources
- releases
- operational logs and run inspection
- Artifacts as job inputs or outputs
This Skill Can Do
- create or review manual jobs
- create or review scheduled jobs
- decide when to use
scheduled_jobs.yaml
- validate and submit batch job files
- decide when strict batch sync is appropriate
- create or select project images
- freeze jobs to a project image
- inspect job runs and logs
- reason about project resources and resource releases
- review Artifact-based workflows in operational pipelines
This Skill Must Not Claim
This skill must not claim ownership of:
- DataNode producer behavior
- SimpleTable schema and row semantics
- FastAPI route contracts
- RBAC or sharing policy
- Streamlit dashboard implementation details
Route Adjacent Work
- DataNodes:
.agents/skills/data_publishing/data_nodes/SKILL.md
- SimpleTables:
.agents/skills/data_publishing/simple_tables/SKILL.md
- APIs and FastAPI:
.agents/skills/application_surfaces/api_surfaces/SKILL.md
- RBAC and sharing:
.agents/skills/platform_operations/access_control_and_sharing/SKILL.md
- Streamlit dashboards:
.agents/skills/dashboards/streamlit/SKILL.md
Read First
docs/tutorial/scheduling_jobs.mddocs/knowledge/infrastructure/scheduling_jobs.mddocs/knowledge/infrastructure/artifacts.md
If the task touches deployed dashboards or APIs, also read the relevant domain skill/docs before changing the operational workflow.
Inputs This Skill Needs
Before changing orchestration or release behavior, collect or infer:
- the execution target:
execution_path- app entrypoint
- whether the job is:
- manual
- interval
- crontab
- one-off
- the image strategy:
- whether the workflow is:
- direct CLI/client job creation
- repository-managed batch scheduling
- whether Artifact inputs or outputs are part of the run
- whether the job should be reproducible against a pinned image
If the execution target or image strategy is unclear, stop before scheduling anything.
Required Decisions
For every non-trivial orchestration task, decide:
- Is this a one-off/manual workflow or a repository-managed recurring workflow?
- Should the jobs live in
scheduled_jobs.yaml?
- Which pinned project image should the job use?
- Is strict batch sync appropriate or dangerous?
- Does the workflow depend on Artifacts?
- Is the task actually a release/resource problem instead of only a job problem?
Build Rules
1. Shared recurring jobs should be treated as code
For shared recurring workflows, prefer:
scheduled_jobs.yamlmainsequence project schedule_batch_jobs ...
Do not hide important recurring schedules in ad hoc shell history or one-off manual commands.
2. Jobs should run against pinned images
Jobs should be pinned to a project image.
Remember:
- images are built from pushed commits
- if a commit is not on the remote, it cannot be used for an image
- unpinned jobs are not an acceptable default in a managed Main Sequence project
3. Jobs must be verifiable after creation
Do not stop at creation.
Verify:
- the job exists
- the run can be triggered or has been triggered
- the logs and run status match expectations
4. Batch scheduling is powerful and dangerous
Use --strict only when the batch file is intended to be the full desired state.
Do not use strict mode casually in shared environments.
5. Artifacts are operational file primitives
Use Artifact when the operational unit is a file.
Examples:
- vendor drops
- generated reports
- model files
- input spreadsheets
Do not force a file workflow into a table workflow too early.
6. Resources and releases are part of deployment, not just code
For deployed dashboards, APIs, or agents:
- the local file is not enough
- the project resource must exist
- the release must exist
- the release must point at the intended image or resource version
Review Rules
When reviewing an orchestration task, look for:
- schedules that should have been version-controlled
- direct job creation where a batch file should exist
- missing or wrong
related_image_id
- jobs tied to moving repository state instead of a pinned image
- no run/log verification after creation
- unsafe use of
--strict
- workflows depending on laptop-specific file paths instead of Artifacts
- tasks that are really resource/release problems rather than simple job problems
Validation Checklist
Do not claim success until you have checked:
- the execution target is correct
- the job mode is correct:
- manual
- interval
- crontab
- one-off
- the pinned image choice is intentional
- the job exists after creation or sync
- runs and logs were inspected when execution success matters
- resources and releases were verified when deployment success matters
If the workflow uses scheduled_jobs.yaml, also check:
- the file shape is valid
- the jobs list is intentional
- strict mode is either intentionally on or intentionally off
If the workflow uses Artifacts, also check:
- the bucket and artifact identity are intentional
- the workflow no longer depends on a fragile local path
This Skill Must Stop And Escalate When
- the execution target is unclear
- the image strategy is unclear but reproducibility matters
- strict batch sync could delete jobs and the desired state is not explicit
- the workflow depends on local file paths that should be platform Artifacts
- the task is actually about RBAC policy rather than orchestration
- the task is actually about producer semantics rather than platform execution
Do not guess through operational state.
