fix: goal-creator now emits task_identifier - #92
Conversation
|
Closing unmerged — the premise was wrong. I proposed this after Checking what goals actually contain:
So this PR would have written a task-shaped key onto every future goal. The real defect is in the linter: Two adjacent findings for whoever picks up the real fix:
Correct fix: make the identifier check page-type aware, or unify both page types behind one neutral key. Either needs a spec, not a one-line agent edit. |
There was a problem hiding this comment.
I now have all the information needed for a thorough review.
Summary of review:
The diff contains exactly two files: CHANGELOG.md (one changelog bullet) and agents/goal-creator.md (one instruction line added to the "Required fields" list in step 8).
Key architectural facts established by code inspection:
-
GoalFrontmatterhas noTaskIdentifier()accessor — unlikeTaskFrontmatterwhich has bothTaskIdentifier()andSetTaskIdentifier(). However,GoalFrontmatterembedsFrontmatterMapand usesGetString(key)for unknown fields, sotask_identifierwritten by the agent will survive round-trips via the generic path (e.g.,GetField("task_identifier")). The field is not lost — it's just not accessed via a typed method. -
No Go code creates goals —
domain.NewGoal()takes a plainmap[string]any; callers populate it. Thegoal-creatoragent (a markdown/Claude instruction file) is what generates the actual file content. The fix is correctly placed in the agent instruction file. -
MISSING_TASK_IDENTIFIERfixability —Fixable: falseis intentional (auto-minting a UUID would silently change identity). The lint message says "run backfill" but the changelog accurately notes this command does not exist. This is a pre-existing UX defect inlint.go:621, not introduced by this PR, and correctly documented in the changelog. -
Changelog accuracy — The bullet accurately describes the bug, the discovery context, and the two related observations (sibling tasks linting clean; backfill command absent).
{
"verdict": "approve",
"summary": "Clean documentation-only fix. The goal-creator agent now instructs itself to emit `task_identifier` in generated goal frontmatter, matching the existing convention in task-creator. No Go code changes; the field survives round-trips via FrontmatterMap. The changelog entry accurately describes the bug, its discovery context, and the related backfill-command UX issue.",
"comments": [],
"concerns_addressed": [
"correctness: agents/goal-creator.md is documentation-only (markdown agent definition); confirmed — no Go code creates goals, the agent instruction is the correct fix location",
"correctness: goal lint --fix reports MISSING_TASK_IDENTIFIER as fixable without actually fixing it — accurately documented in the CHANGELOG.md bullet; pre-existing lint.go UX defect, not introduced by this PR"
]
}
Problem
goal-creatornever emittedtask_identifier, so every goal it created failedgoal linton the first check:goal lint --fixdoes not repair it, so the operator has to generate a UUID by hand and rungoal set.task-creator.mdhas carried the equivalent instruction all along (agents/task-creator.md:120) — the goal side was simply missing it.Fix
One line added to the required-frontmatter list in
agents/goal-creator.md, mirroring the task-creator wording.Evidence
Found 2026-08-17 while scaffolding a goal via
/jira-sprint-sync: all five sibling tasks created bytask-creatorin the same run linted clean, and only the goal failed.Not fixed here
The lint hint names a
backfillcommand that does not exist onvault-cli goal, andgoal lint --fixreportsMISSING_TASK_IDENTIFIERas fixable without fixing it. Both are Go-side; this change makes the common path moot but does not address them.