Release he-maintainer v1

he-maintainer/references/scoring-rubric.md

@@ -5,34 +5,44 @@ Use this when asked to audit or score a repository's harness quality.
 ## Dimensions
 
 ### 1. Project map clarity
-- strong: key directories and entrypoints are documented and current
-- partial: some structure is documented but stale or incomplete
+- strong: key directories, entrypoints, and subsystem boundaries are documented and current
+- partial: some structure is documented but stale, shallow, or incomplete
 - weak: little or no useful repo map exists
 
 ### 2. Validation commands
-- strong: build, test, lint, and typecheck are clear and runnable
-- partial: some commands exist but are incomplete or ambiguous
-- weak: commands are missing, stale, or unverified
+- strong: build, test, lint, typecheck, or equivalent validation commands are clear and runnable
+- partial: some commands exist but are incomplete, stale, or ambiguous
+- weak: commands are missing, misleading, or unverified
 
 ### 3. Fast feedback
-- strong: targeted checks or quick tests exist
-- partial: only slower validation exists
-- weak: no obvious quick validation path
+- strong: targeted package-, crate-, app-, or feature-scoped checks exist
+- partial: only slower validation paths exist, or quick checks are incomplete
+- weak: no obvious fast validation path exists
 
-### 4. Task templates
-- strong: reusable templates exist for common work types
-- partial: ad hoc instructions exist but are inconsistent
-- weak: every task must be reinvented
+### 4. Task contract quality
+- strong: reusable task contracts or templates define scope, constraints, validation, and acceptance criteria
+- partial: ad hoc task instructions exist but are inconsistent or underspecified
+- weak: every task must be reinvented from scratch
 
 ### 5. Guardrails
-- strong: high-risk areas and forbidden changes are explicit
-- partial: some constraints exist but are vague
-- weak: almost no constraints are documented
+- strong: high-risk areas, forbidden changes, generated-file boundaries, and slow validations are explicit
+- partial: some constraints exist but are vague or fragmented
+- weak: almost no meaningful constraints are documented
 
-### 6. Doc-code alignment
-- strong: harness docs match the current repo layout and commands
-- partial: mixed accuracy
-- weak: obviously stale or misleading
+### 6. Architecture decision durability
+- strong: durable decisions are easy to find in ADRs, accepted docs, or equivalent records
+- partial: some decisions are documented but scattered, stale, or inconsistently applied
+- weak: important architecture or workflow decisions must be rediscovered from chat or code archaeology
+
+### 7. Failure feedback loop quality
+- strong: repeated AI or implementation failures are converted into durable harness, validation, or CI improvements
+- partial: some failures are documented, but fixes remain mostly conversational or one-off
+- weak: the same classes of failure recur without system updates
+
+### 8. Doc-code alignment
+- strong: harness docs match the current repo layout, commands, and constraints
+- partial: mixed accuracy with some stale sections
+- weak: obviously stale or misleading guidance dominates
 
 ## Output format
 
@@ -41,11 +51,13 @@ Keep the score compact. Example:
 - project map clarity: partial
 - validation commands: strong
 - fast feedback: weak
-- task templates: weak
+- task contract quality: weak
 - guardrails: partial
+- architecture decision durability: weak
+- failure feedback loop quality: weak
 - doc-code alignment: partial
 
 Top priorities:
-1. Add a fast unit test or package-scoped validation command
-2. Refresh AGENTS.md directory map
-3. Document forbidden change areas
+1. Add a targeted validation command for the touched package or crate
+2. Record one durable architecture decision in an ADR or accepted design note
+3. Turn the most common repeated failure into a task-contract, guardrail, or CI rule