coding-artifact-evaluation-shell 0.1.0-eidolon.a1a6ca75ec65e → 0.1.0-eidolon.a1b37cbcd7c07

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "coding-artifact-evaluation-shell",
-  "version": "0.1.0-eidolon.a1a6ca75ec65e",
+  "version": "0.1.0-eidolon.a1b37cbcd7c07",
   "private": false,
   "type": "module",
   "description": "Code-development artifact evaluator and code-first Halfcode SkillApp",

package/resources/review.md

@@ -14,8 +14,6 @@ Read COMPLETE originals first; preserve each independent qualifier, modality and
 Evidence must distinguish the promised consumer PURPOSE, not just setup/access/empty state. Genuine tests count for what their real seams/assertions exercise: cite BOTH their definition and native execution; a replaced entrance is not proven even when other dependencies are real. Ask which required failure a test detects. Temporal/causal/lifecycle requirements need observations distinguishing those conditions, not final values alone. Free-text probe conditions describe intent; neither a word such as "settled" nor tool completion proves business completion. For absence require established prerequisites and an observed completion/deadline, not immediate silence: unknown completion means indeterminate; an unavailable environment prerequisite is not a business capability failure. Representative acceptance is finite sampling; disclose limits without waiving material conditions. No exhaustive branch checklist is required; equivalent observable semantics count unless originals mandate the form.
 Derive expected outcomes before comparison; artifact output, exit 0, coverage labels and self-assertions never define the goal. PASS needs all required conditions; FAIL needs an applicable original contradiction surviving valid alternative readings/implementations; missing or ambiguous evidence is indeterminate. Keep judgments consistent with comparisons and findings. Actual facts and finite sampling are not universal proofs.
 
-Fix the relevant acceptance boundary from the originals before judging a discovered implementation. Additional routes, controls or graph hits do not silently expand that boundary: a contradiction on an optional surface needs an original constraint whose quantifier actually covers it; preserve genuinely global constraints as global. If plausible original-scope readings would change the outcome and the supplied sources do not resolve them, record that specific ambiguity and remain indeterminate instead of selecting whichever reading makes this attempt PASS or FAIL. A limitation cannot disclaim a required condition while certifying that same condition. Likewise, missing execution alone does not invalidate a source-provable static requirement; distinguish those objects rather than applying a blanket UI/E2E rule.
-
 Describe evidence depth per comparison, using existing fields: `method` names what actually happened (source inspection, symbol/call tracing, executed tests, integration or consumer observation); `conditions` identifies the assessed boundary, artifact/version and actual execution or historical conditions; `reasoning` states which required distinctions the evidence covers; `limitations` identifies material uncovered distinctions and why. This supports a scope | actual method/depth | coverage | judgment | gap view without extra output keys, a second score, or mandatory repeated checklists. A requested depth label is an operational plan, never evidence that the work happened. Keep explanations concise and reuse evidence references.
 
 Scope, method, depth and coverage are independent: scope selects the authorized object/requirements; methods obtain facts; depth describes how far the actual investigation followed relevant dependencies, transitions, error paths or counterexamples; coverage states inspected versus unassessed conditions. Choose the least costly sufficient evidence for each original requirement, deepening only for a material unresolved distinction within available capabilities and the same budget. Static architecture/deliverable requirements can be established by adequate source inspection without executing E2E; passing tests or a successful consumer journey do not establish unrelated architecture or all branches. Neither add generic testing/E2E/process obligations nor silently waive frozen original conditions. A deliberately unperformed method is not itself a failed requirement; an original behavioral condition still lacking support remains unresolved.