# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## CTYPE — A small expression type checker with explainable errors Fictional rules editor Willow supports numbers, strings, booleans, records and functions in a deliberately small language. Define syntax and type rules locally; no arbitrary code execution is needed. **Field:** Compiler and language tooling. **Suggested stack:** TypeScript, Vitest, Typed AST fixtures. **Engineer value:** Practice type environments, unification and explainable rejection. **Company value:** Inspect whether developer tooling catches mistakes without hiding uncertainty. **Delivery agreement:** Limit scope to the declared type system; general language compatibility is not claimed. ### Setup prerequisites - Create synthetic AST fixtures and a written type-rule table. - Define source spans and structured diagnostic output. ### Establish type rules Handle literals and lexical scope. #### CTYPE-101 — Assign explicit types to rules-editor literals **Task · Medium priority · Foundational** noCV practice brief v5 · CTYPE-101 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The prototype infers booleans from string truthiness. Type literals from AST node kinds only. Acceptance criteria - Number string and boolean types differ - Empty string stays string - Unknown literal kind fails explicitly Implementation constraints - Do not evaluate literal source text. Verification - Check each supported literal - Reject unsupported node kind Deliverables - Literal checker and cases Rollout and recovery: Reject unknown nodes while supported literals remain available. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-102 — Resolve expression identifiers through lexical scope **Bug · High priority · Intermediate** noCV practice brief v5 · CTYPE-102 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: CTYPE-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Inner bindings overwrite the global environment and leak into sibling expressions. Use scoped environments. Acceptance criteria - Inner shadowing is local - Sibling scope remains unchanged - Unbound names include source location Implementation constraints - Environments must not mutate parent bindings accidentally. Verification - Check nested shadowing - Use name outside its scope Deliverables - Scope resolver and cases Rollout and recovery: Disable nested bindings if scope isolation fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-103 — Explain rules-editor operator operand mismatches **Story · Medium priority · Foundational** noCV practice brief v5 · CTYPE-103 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish type rules. Depends on: CTYPE-101, CTYPE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Invalid addition reports Type error without naming either operand type. Add structured expected and actual types. Acceptance criteria - Valid operands infer result - Mismatch identifies operator span - Diagnostic includes both operand types Implementation constraints - Keep wording independent from internal object serialization. Verification - Add two numeric literals - Add number to unsupported record Deliverables - Operator rules and diagnostic cases Rollout and recovery: Reject ambiguous operators with explicit unsupported message. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Resolve expression types Explain composition failures. #### CTYPE-104 — Check function calls for arity before argument inference **Task · Medium priority · Intermediate** noCV practice brief v5 · CTYPE-104 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-102, CTYPE-103. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Calling a two-argument function with one argument crashes inference. Validate arity and check only supplied expressions safely. Acceptance criteria - Correct arity checks all arguments - Wrong arity reports counts - Nested argument errors remain inspectable Implementation constraints - Avoid fabricating missing AST nodes. Verification - Check valid call - Call with too few and too many arguments Deliverables - Call checker and arity cases Rollout and recovery: Disable call inference for malformed ASTs. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-105 — Unify rules-editor type variables with an occurs check **Bug · High priority · Expert** noCV practice brief v5 · CTYPE-105 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A recursive synthetic constraint produces an infinite inferred type. Reject self-containing substitutions. Acceptance criteria - Acyclic constraints unify - Recursive substitution fails with reason - Failure does not corrupt remaining environment Implementation constraints - Bound this ticket to monomorphic variable unification. Verification - Unify variable with number - Attempt variable equal to function containing itself Deliverables - Unifier and occurs-check cases Rollout and recovery: Disable variable inference if substitution integrity fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-106 — Report missing rules-editor record fields without losing known fields **Story · Medium priority · Advanced** noCV practice brief v5 · CTYPE-106 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-103, CTYPE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Reading an absent field turns the whole record into unknown and suppresses later valid diagnostics. Preserve field-level information. Acceptance criteria - Existing field returns declared type - Missing field names available keys within a cap - Later checks retain known types Implementation constraints - Do not expose arbitrary source values in diagnostics. Verification - Access known field - Access absent field then known field Deliverables - Record-access rule and recovery cases Rollout and recovery: Reject absent-field expression only while preserving surrounding scope. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-107 — Merge rules-editor branch types through explicit compatibility rules **Task · High priority · Advanced** noCV practice brief v5 · CTYPE-107 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Resolve expression types. Depends on: CTYPE-105, CTYPE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Conditional branches return incompatible values but the checker chooses the first branch type. Define their common result rule. Acceptance criteria - Compatible branches infer documented type - Incompatible branches report both spans - Condition must be boolean Implementation constraints - Do not introduce implicit coercion without a declared rule. Verification - Check matching branches - Check number versus record branches Deliverables - Conditional rule and compatibility cases Rollout and recovery: Reject mixed branches until the rule is stable. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Keep checking predictable Bound work and stabilize diagnostics. #### CTYPE-108 — Make rules-editor diagnostics deterministic across map insertion order **Bug · Medium priority · Intermediate** noCV practice brief v5 · CTYPE-108 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-106, CTYPE-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Equivalent AST construction order changes diagnostic output and noisy snapshots. Sort by source and stable category. Acceptance criteria - Equivalent inputs yield same order - Related locations stay attached - Equal-span tie-breaking is documented Implementation constraints - Determinism must not remove distinct failures. Verification - Reorder environment construction - Create two same-span categories Deliverables - Diagnostic ordering and cases Rollout and recovery: Preserve stable source traversal if sorting loses relationships. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-109 — Cancel obsolete rules-editor checks without publishing stale results **Story · Medium priority · Advanced** noCV practice brief v5 · CTYPE-109 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-107, CTYPE-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 80% · Performance engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Editor edits finish out of order and older type errors replace current diagnostics. Scope checking to document version. Acceptance criteria - Only current version publishes - Cancellation releases resources - Late completion cannot overwrite Implementation constraints - Include document identity as well as version. Verification - Complete current check - Resolve old check after replacement Deliverables - Versioned checking coordinator Rollout and recovery: Run serial checks if publication ownership fails. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### CTYPE-110 — Bound rules-editor inference work with explicit incomplete status **Chore · Medium priority · Expert** noCV practice brief v5 · CTYPE-110 · A small expression type checker with explainable errors Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Keep checking predictable. Depends on: CTYPE-105, CTYPE-109. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Compiler and language tooling 60% · Performance engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Adversarial nested constraints consume excessive work. Add operation and depth budgets with honest termination status. Acceptance criteria - Supported fixtures complete - Budget exhaustion is explicit - Incomplete checks cannot claim type safety Implementation constraints - Use deterministic counters rather than wall time alone. Verification - Check normal corpus - Exceed constraint budget Deliverables - Inference budget and stress cases Rollout and recovery: Lower limits and mark affected files incomplete until improved. Project prerequisites: Create synthetic AST fixtures and a written type-rule table. Define source spans and structured diagnostic output. Engineer value: Practice type environments, unification and explainable rejection. Company value: Inspect whether developer tooling catches mistakes without hiding uncertainty. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.