# WhetstoneDSL Gate Inventory ## Purpose This document grounds `whetstone_RSA` Phase 1 in the actual decision surfaces currently present in `whetstone_DSL`. It is intentionally narrower than a general architecture document. The goal is to answer: - what bounded decisions already exist in the `whetstone_DSL` taskitem and AST-codegen pipeline - which of those are already deterministic - which are immediate RSA case-study candidates - which should become semantic skeletons first before any specialist training This inventory is based on the current code surfaces in: - `editor/src/TaskitemGeneratorV2.h` - `editor/src/TaskitemConfidenceAmbiguity.h` - `editor/src/RoutingEngine.h` - `editor/src/mcp/RegisterArchitectIntakeTools.h` - `editor/src/ast/ProjectionGenerator.h` - `editor/src/CrossLanguageProjector.h` - `editor/src/ConstrainedProjectionGate.h` - `editor/src/mcp/RegisterCppRaisingTools.h` ## Architectural Observation The strongest current RSA surface in `whetstone_DSL` is not the final language-emission step. Once the AST and target language are fixed, most current code generation is already deterministic: - target generator dispatch is deterministic - AST concept dispatch is deterministic - environment gating is deterministic - C++ raising profile validation is deterministic That means the immediate RSA case-study value is higher in: - taskitem generation - execution-contract shaping - routing - pre-codegen bounded profile decisions than in raw syntax emission. ## Current Decision Surfaces ### A. Taskitem decomposition and planning Observed decisions: - milestone grouping - workstream grouping - workstream title shape - workstream intent aggregation - uncertainty scoring Current implementation state: - largely heuristic and deterministic in `ScopeMilestoneDecomposer` - not yet expressed as explicit RSA gate contracts Assessment: - milestone grouping is currently deterministic and should remain so until a real ambiguity signal shows otherwise - uncertainty scoring is currently formula-like and should remain deterministic - title shaping is mixed: parts are deterministic formatting, but some grouping and summary choices are latent semantic decisions RSA relevance: - weak immediate training target - good semantic-skeleton target Suggested skeleton entities: - `WorkstreamGroupingDecision` - `MilestoneGroupingDecision` - `WorkstreamSummaryPolicy` ### B. Taskitem worker-type assignment Observed decision: - `implementer | reviewer | architect | qa` Current implementation state: - keyword heuristic in `TaskitemGeneratorV2::inferWorkerType` - file comment explicitly says this is a placeholder to be replaced by a `worker_type` specialist Assessment: - clear bounded enum - direct downstream deterministic meaning - already known from specialist experiments RSA relevance: - immediate case-study gate Recommended gate class: - bounded multiclass gate Likely failure risks: - label-space mismatch - missing context gate ### C. Taskitem prerequisite-op assignment Observed decision: - `validate-intake` - `architect-review` - `resolve-dependencies` Current implementation state: - deterministic default plus uncertainty-based add-on in `TaskitemGeneratorV2::inferPrerequisiteOps` - comments explicitly note this is a placeholder for a future `prereq_op_selector` specialist Assessment: - this is not purely one flat label - it is closer to a bounded structured output or factorized multi-label gate RSA relevance: - immediate case-study gate - especially important for factorization probes Recommended gate shape: - factorized or multi-label, not naive flat multiclass Likely failure risks: - factorizable gate - label-space mismatch ### D. Confidence / ambiguity / escalation Observed decisions: - confidence score `0..100` - ambiguity count - escalate `true|false` Current implementation state: - formulaic in `TaskitemConfidenceAmbiguity` Assessment: - this is the strongest current example of a deterministic-disguised-as-ML gate RSA relevance: - important as negative evidence - should stay deterministic unless a later richer policy surface emerges Recommended disposition: - deterministic layer, not RSA ### E. Routing decision Observed decisions: - worker type: `deterministic | template | slm | llm | human` - context width: `local | file | project | cross-project` - review required - agent role: `linter | refactor | generator` Current implementation state: - deterministic rule cascade in `RoutingEngine` - explicit override path plus heuristic fallbacks Assessment: - routing is already modeled as a bounded decision surface - the current engine is a rule baseline - this is a strong later RSA case study, but not the first one RSA relevance: - important second-wave case study - especially useful for comparing deterministic baseline versus RSA gate quality Recommended disposition: - keep current deterministic routing as baseline - use it later as benchmark data for RSA substitution or hybrid routing ### F. Execution-contract shaping Observed decisions in `RegisterArchitectIntakeTools`: - target file inference - required tool inference - acceptance-command inference - cross-project target inference - verification type inference: `unit | schema | docs | smoke` - step-id inference: `inspect_scope`, `implement_changes`, `apply_changes`, `run_unit_verification`, `run_smoke_verification`, etc. - resource-lock inference Assessment by subtype: - target-file inference: mixed, partly lexical and partly semantic - required-tool inference: bounded and meaningful - verification type: strong existing specialist case - step-id inference: bounded structured sequence; good future structured-output RSA case - resource locks: likely deterministic unless concurrency semantics become richer RSA relevance: - `verification_type` is immediate - execution-contract shaping is a strong structured-output frontier Recommended split: - immediate RSA gates: - `verification_type` - semantic skeleton first: - `ExecutionContractShapeDecision` - `TargetFileSelectionDecision` - `AcceptanceCommandSelectionDecision` - `StepSequenceDecision` ### G. AST projection / code generation Observed decisions: - target language selection - AST node dispatch to language-specific visitor - annotation-preserving cross-language projection - environment constraint gating - C++ raising profile: `safe-first | perf-first | interop-first` Current implementation state: - almost entirely deterministic once target language and profile are provided Assessment: - generator dispatch itself is not the best current RSA surface - the richer opportunity is in bounded pre-codegen policy selection, not in token-level syntax generation RSA relevance: - immediate gate candidate: `cpp_raising_profile` - skeleton-first targets: - `ProjectionProfileDecision` - `ErrorModelPolicyDecision` - `OwnershipMappingProfileDecision` - `AsyncMappingPolicyDecision` ## Inventory Table | Decision surface | Current form | Best current layer | | --- | --- | --- | | `worker_type` | bounded enum | RSA immediate | | `prereq_op_selector` | bounded structured / factorized | RSA immediate | | `verification_type` | bounded enum | RSA immediate | | `confidence_tier` / `escalate` | formula-like | deterministic | | milestone grouping | heuristic grouping | semantic skeleton first | | workstream summary/title | mixed heuristic | semantic skeleton first | | routing layer selection | bounded enum with strong rules | deterministic baseline, later RSA | | target-file inference | mixed bounded selection | semantic skeleton first | | acceptance-command inference | bounded selection | semantic skeleton first | | step-sequence inference | bounded structured sequence | semantic skeleton first | | resource locks | bounded selection | deterministic | | generator dispatch by language | deterministic | deterministic | | C++ raising profile | bounded enum | RSA immediate or near-immediate | ## Recommended Implementation Order ### 1. Immediate RSA gate cases Use the already-observed bounded gates first: - `verification_type` - `worker_type` - `prereq_op_selector` - `cpp_raising_profile` These are the best first fit because they already have: - small output vocabularies - deterministic downstream meaning - clear failure consequences - real code paths in `whetstone_DSL` ### 2. Skeleton before specialist Before training more specialists, define explicit semantic skeletons for: - workstream grouping - execution contract shaping - target-file selection - acceptance-command selection - step-sequence selection These are not yet clean enough as training targets because the semantic contract is still implicit in heuristics. ### 3. Second-wave RSA cases After the skeleton pass: - routing layer selection - routing context-width selection - richer codegen profile selection - backend-policy decisions in IR raising ## Implication For Sprint 002 Sprint 002 should not jump straight from the current C++ RSA scaffold into model training. It should first ensure the semantic model can express at least these categories: - bounded enum gate - factorized / structured-output gate - deterministic baseline attached to a candidate gate - downstream deterministic executor contract - failure diagnosis for factorization and schema drift That semantic coverage is required to represent the real `whetstone_DSL` surfaces above. ## Concrete Next Step Define Whetstone-authored semantic entities for the first four case-study gates: - `VerificationTypeGate` - `WorkerTypeGate` - `PrereqOpGate` - `CppRaisingProfileGate` and define skeleton semantic entities for: - `ExecutionContractShapeDecision` - `WorkstreamGroupingDecision` - `TargetFileSelectionDecision` That would let `whetstone_RSA` move from generic architecture language into a usable case-study-grounded semantic bootstrap.