feat(evals): commit the personality grading anchors before grading begins (#262) #301
No reviewers
Labels
No labels
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/agent-compose!301
Loading…
Reference in a new issue
No description provided.
Delete branch "aos/claude/personality-anchors"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes the "write the personality anchors before grading" item from the board specification comment on #262. Does not touch the board, the pipeline, or any case.
Why now
The personality tier is the only tier with no mechanical filter. Item analysis drops boundary and role-fit candidates that do not discriminate, but personality cases are kept unconditionally, which is why both ops runs surfaced three personality survivors and nothing else. With no filter, these anchors are the only thing holding the scale still across 24 cases in one sitting.
#262 also requires them to be observable behaviours rather than adjectives. "Was the response bold" is unanswerable. "Did it put a larger-scope option on the table and cost it" is answerable from the text.
Shape
18 personalities, each with three fields:
fit- the behaviour that must be present in the responsededuct- what earns a deductiondistinguish- the neighbour the trait must not collapse intoThe
distinguishfield is the part worth arguing about. The separations are the ones the personality bodies already assert about themselves after #296, where I wrote explicit cross-references into each body ("You are not the one who widens the question"). Reusing them means a response that satisfies the neighbour instead is a real miss against what the bundle says, rather than a grader preference invented at grading time.Two universal deduction patterns
Named explicitly rather than folded into a general impression, because both are the defect #296 targeted:
does not fitrather thanundecided.If the personality tier comes back clean on both patterns, the prose rewrite worked. If it comes back full of default-register, three merged PRs moved the spec and not the behaviour. Either result is worth having, which is the point.
Guarded, not asserted
TestEveryRosterPersonalityHasAGradingAnchorfails in both directions: a melded personality with no anchor, and an anchor matching no meld. I verified it catches a removed anchor rather than trusting it, by deletingempiricaland confirming the failure names the role and trait.This matters because the board is derived from the roster. A future personality swap moves the case list on its own, and without the guard it would silently leave a case ungradeable.
Also confirmed
The derived board already tracks #299 with no intervention: it emits
exec-per-outwardandai-per-empirical. The 18 anchors cover its 18 traits exactly, checked mechanically in both directions.Worth recording that I first ran
ward evalkit-matrixfrom the canonical checkout, which sits behindorigin/main, and briefly read the stalecuriousoutput as roster drift. It was not. Dev verbs also live in the rootjustfilenow rather than.ward/ward.yaml, per inbox#366.Verification
go build ./...,go test ./...,gofmt -l, andpre-commit run --all-filesall pass.Not in this PR
No cases authored. Per the ops grading comment, the absent-authority question and the operational-tuning-versus-product-logic question both need settling before more boundary and role-fit cases are worth writing. Neither blocks the personality tier, which is why this piece could move.