The safe-jobs top-level frontmatter field is accessed in compiler code but is not defined in the schema, and its relationship to safe-outputs.jobs is unclear, leading to API confusion and potential misuse.
Source
Extracted from Schema Consistency Analysis discussion #11121 and Safe-Outputs Comprehensive Audit #12389
Problem
Current State:
safe-jobs is accessed in pkg/workflow/safe_jobs.go:40 via frontmatter["safe-jobs"]
- NOT defined in
main_workflow_schema.json (0 of 38 top-level properties)
- Code comment suggests: "User workflows should use 'safe-outputs.jobs' syntax; the top-level 'safe-jobs' key is NOT supported."
- Yet compiler still accesses
frontmatter["safe-jobs"] directly
Confusion:
- Is
safe-jobs a valid user-facing field or internal-only?
- What's the relationship between
safe-jobs and safe-outputs.jobs?
- Should users use one, the other, or both?
Files Affected
pkg/workflow/safe_jobs.go - Contains implementation and comment
pkg/parser/schemas/main_workflow_schema.json - Missing schema definition
docs/src/content/docs/reference/frontmatter.md - Not documented
docs/src/content/docs/reference/compilation-process.md:270 - Mentions but doesn't explain
Suggested Resolution (Choose One)
Option 1: Internal-Only (Recommended)
- Remove
frontmatter["safe-jobs"] direct access
- Document that users MUST use
safe-outputs.jobs syntax
- Update all examples to show correct usage
Option 2: User-Facing
- Add
safe-jobs to schema with proper validation
- Document when to use
safe-jobs vs safe-outputs.jobs
- Add examples showing both approaches
Option 3: Alias Pattern
- Keep both but document as aliases
- Add schema validation for consistency
- Show migration path in docs
Investigation Needed
- Review git history: Why was
safe-jobs added? Was it meant to be user-facing?
- Check test files: Are there tests using top-level
safe-jobs?
- Search workflows: Are any workflows currently using
safe-jobs directly?
- Determine intended behavior: What should happen if both are specified?
Success Criteria
- Clear decision made: internal-only, user-facing, or alias
- Schema updated accordingly
- Documentation reflects correct usage
- Code comments explain the pattern
- No ambiguity about which syntax to use
Priority
Medium - API clarity issue that could lead to misuse, but not blocking current functionality. Important for maintaining clean API surface.
Estimated Effort
3-4 hours - Requires investigation, decision-making, code updates, schema changes, and documentation.
AI generated by Discussion Task Miner - Code Quality Improvement Agent
The
safe-jobstop-level frontmatter field is accessed in compiler code but is not defined in the schema, and its relationship tosafe-outputs.jobsis unclear, leading to API confusion and potential misuse.Source
Extracted from Schema Consistency Analysis discussion #11121 and Safe-Outputs Comprehensive Audit #12389
Problem
Current State:
safe-jobsis accessed inpkg/workflow/safe_jobs.go:40viafrontmatter["safe-jobs"]main_workflow_schema.json(0 of 38 top-level properties)frontmatter["safe-jobs"]directlyConfusion:
safe-jobsa valid user-facing field or internal-only?safe-jobsandsafe-outputs.jobs?Files Affected
pkg/workflow/safe_jobs.go- Contains implementation and commentpkg/parser/schemas/main_workflow_schema.json- Missing schema definitiondocs/src/content/docs/reference/frontmatter.md- Not documenteddocs/src/content/docs/reference/compilation-process.md:270- Mentions but doesn't explainSuggested Resolution (Choose One)
Option 1: Internal-Only (Recommended)
frontmatter["safe-jobs"]direct accesssafe-outputs.jobssyntaxOption 2: User-Facing
safe-jobsto schema with proper validationsafe-jobsvssafe-outputs.jobsOption 3: Alias Pattern
Investigation Needed
safe-jobsadded? Was it meant to be user-facing?safe-jobs?safe-jobsdirectly?Success Criteria
Priority
Medium - API clarity issue that could lead to misuse, but not blocking current functionality. Important for maintaining clean API surface.
Estimated Effort
3-4 hours - Requires investigation, decision-making, code updates, schema changes, and documentation.