@dannylee1020/kkt 0.5.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (50) hide show
  1. package/LICENSE +201 -0
  2. package/README.md +275 -0
  3. package/assets/kkt-readme-modern.png +0 -0
  4. package/bin/kkt-install.mjs +25 -0
  5. package/cmd/kkt/main.go +15 -0
  6. package/go.mod +3 -0
  7. package/internal/workflow/cli.go +349 -0
  8. package/internal/workflow/cli_test.go +1266 -0
  9. package/internal/workflow/guardrails.go +900 -0
  10. package/internal/workflow/init.go +164 -0
  11. package/internal/workflow/init_test.go +113 -0
  12. package/internal/workflow/operations.go +1855 -0
  13. package/internal/workflow/validation_commands.go +291 -0
  14. package/internal/workflow/workspace.go +802 -0
  15. package/internal/workflow/workspace_test.go +285 -0
  16. package/package.json +45 -0
  17. package/scripts/install-cli.sh +210 -0
  18. package/scripts/install.sh +644 -0
  19. package/skills/kkt/SKILL.md +74 -0
  20. package/skills/kkt/references/discovery-tooling.md +53 -0
  21. package/skills/kkt/references/feature-optimization-model.md +120 -0
  22. package/skills/kkt/references/kkt-kernel.md +58 -0
  23. package/skills/kkt/references/layered-modeling-methods.md +101 -0
  24. package/skills/kkt/references/plan-assimilation.md +46 -0
  25. package/skills/kkt/references/schemas.md +231 -0
  26. package/skills/kkt/references/state-contract.md +76 -0
  27. package/skills/kkt-loop/SKILL.md +99 -0
  28. package/skills/kkt-loop/references/discovery-tooling.md +53 -0
  29. package/skills/kkt-loop/references/feature-optimization-model.md +120 -0
  30. package/skills/kkt-loop/references/kkt-kernel.md +58 -0
  31. package/skills/kkt-loop/references/layered-modeling-methods.md +101 -0
  32. package/skills/kkt-loop/references/plan-assimilation.md +46 -0
  33. package/skills/kkt-loop/references/schemas.md +231 -0
  34. package/skills/kkt-loop/references/state-contract.md +76 -0
  35. package/skills/kkt-model/SKILL.md +76 -0
  36. package/skills/kkt-model/references/discovery-tooling.md +53 -0
  37. package/skills/kkt-model/references/feature-optimization-model.md +120 -0
  38. package/skills/kkt-model/references/kkt-kernel.md +58 -0
  39. package/skills/kkt-model/references/layered-modeling-methods.md +101 -0
  40. package/skills/kkt-model/references/plan-assimilation.md +46 -0
  41. package/skills/kkt-model/references/schemas.md +231 -0
  42. package/skills/kkt-model/references/state-contract.md +76 -0
  43. package/skills/kkt-run/SKILL.md +62 -0
  44. package/skills/kkt-run/references/discovery-tooling.md +53 -0
  45. package/skills/kkt-run/references/feature-optimization-model.md +120 -0
  46. package/skills/kkt-run/references/kkt-kernel.md +58 -0
  47. package/skills/kkt-run/references/layered-modeling-methods.md +101 -0
  48. package/skills/kkt-run/references/plan-assimilation.md +46 -0
  49. package/skills/kkt-run/references/schemas.md +231 -0
  50. package/skills/kkt-run/references/state-contract.md +76 -0
@@ -0,0 +1,231 @@
1
+ # KKT Schemas
2
+
3
+ Optional reference for copyable shapes. Do not load this on every invocation; use it when writing or auditing durable KKT state, layer contracts, plan-assimilation output, discovery tooling output, or guardrails.
4
+
5
+ ## Layer Contract
6
+
7
+ ```yaml
8
+ layer_contract:
9
+ layer:
10
+ status: pending | complete | blocked
11
+ method_used:
12
+ inputs_consumed:
13
+ outputs:
14
+ decisions:
15
+ assumptions:
16
+ unknowns:
17
+ artifact_refs:
18
+ next_layer_readiness:
19
+ ```
20
+
21
+ ## Optimized Plan
22
+
23
+ ```yaml
24
+ optimized_plan:
25
+ objective_function:
26
+ known_constraints:
27
+ explicit:
28
+ discovered:
29
+ inferred:
30
+ assumptions:
31
+ decision_variables:
32
+ - name:
33
+ allowed_domain:
34
+ chosen_value:
35
+ rationale:
36
+ files_to_modify:
37
+ - path_or_surface:
38
+ change_type:
39
+ rationale:
40
+ constraint_functions:
41
+ hard:
42
+ - name:
43
+ predicate:
44
+ source:
45
+ status:
46
+ soft:
47
+ - name:
48
+ preference:
49
+ source:
50
+ status:
51
+ candidates:
52
+ feasible:
53
+ rejected:
54
+ selected_plan:
55
+ binding_constraints:
56
+ validation_plan:
57
+ validation_proof:
58
+ execution_implications:
59
+ guardrail_variables:
60
+ residual_risk:
61
+ ```
62
+
63
+ ## Plan Assimilation
64
+
65
+ ```yaml
66
+ plan_assimilation:
67
+ source:
68
+ original_request:
69
+ prior_plan_text:
70
+ extracted_signals:
71
+ proposed_goal:
72
+ proposed_steps:
73
+ suspected_surfaces:
74
+ implied_constraints:
75
+ validation_suggestions:
76
+ open_questions:
77
+ risk_signals:
78
+ classification:
79
+ explicit_user_input:
80
+ plan_assumption:
81
+ discoverable_fact:
82
+ candidate_decision:
83
+ candidate_constraint:
84
+ candidate_validation:
85
+ unknown_or_ambiguous:
86
+ verification:
87
+ verified_facts:
88
+ rejected_claims:
89
+ assumptions_carried:
90
+ searches_or_evidence:
91
+ next_layer_readiness:
92
+ ```
93
+
94
+ ## Discovery Tooling
95
+
96
+ ```yaml
97
+ discovery_tooling:
98
+ available:
99
+ core:
100
+ preferred:
101
+ optional:
102
+ language_native:
103
+ unavailable:
104
+ searches:
105
+ - tool:
106
+ purpose:
107
+ query_or_pattern:
108
+ paths:
109
+ result_summary:
110
+ confidence:
111
+ negative_searches:
112
+ - tool:
113
+ query_or_pattern:
114
+ paths:
115
+ implication:
116
+ fallback_notes:
117
+ ```
118
+
119
+ ## Execution Contract
120
+
121
+ ```yaml
122
+ execution_contract:
123
+ acceptance_criteria:
124
+ validation_plan:
125
+ evidence_required:
126
+ stop_conditions:
127
+ continuation_policy:
128
+ ```
129
+
130
+ ## kkt.yaml
131
+
132
+ ```yaml
133
+ schema_version: 1
134
+ workspace_type: plan | model | run | loop
135
+ profile: plan | model | run | loop
136
+ status: initialized | modeling | approved | executing | validating | complete | blocked
137
+ active_layer: intent | discovery | modeling | execution | validation
138
+ layers:
139
+ intent:
140
+ status: pending | complete | blocked
141
+ method: pending | goal_anti_goal | why_how | obstacle_questions | pairwise_questions
142
+ summary: ""
143
+ artifact: intent.md
144
+ discovery:
145
+ status: pending | complete | blocked
146
+ method: pending | naive | traceability_matrix | coupling_map | dsm_lite
147
+ summary: ""
148
+ artifact: discovery.md
149
+ modeling:
150
+ status: pending | complete | blocked
151
+ method: pending | lexicographic | decision_tree | shortest_path | ordinal_mcda | pairwise_ahp | outranking
152
+ summary: ""
153
+ artifact: model.md
154
+ execution:
155
+ status: pending | complete | blocked
156
+ method: pending | smallest_feasible_step | contract_preserving_change
157
+ summary: ""
158
+ artifact: plan.md
159
+ validation:
160
+ status: pending | complete | blocked
161
+ method: pending | acceptance_map | hard_constraint_audit | binding_constraint_audit
162
+ summary: ""
163
+ artifact: evidence.md
164
+ method_invocations: []
165
+ decision_log: []
166
+ planning_contract:
167
+ objective_function:
168
+ files_to_modify:
169
+ constraint_functions:
170
+ decision_variables:
171
+ validation_proof:
172
+ artifact_refs:
173
+ approval:
174
+ required: true
175
+ status: not_required | pending | approved | rejected
176
+ approved_scope:
177
+ stop_conditions: []
178
+ loop_state:
179
+ current_task: ""
180
+ tasks: []
181
+ acceptance_criteria: []
182
+ evidence: []
183
+ stop_conditions: []
184
+ ```
185
+
186
+ ## guardrails.json
187
+
188
+ ```json
189
+ {
190
+ "schema_version": 1,
191
+ "source": {
192
+ "workspace_type": "model",
193
+ "workspace": ".kkt/model/<slug>",
194
+ "request": ""
195
+ },
196
+ "constraints": [
197
+ {
198
+ "id": "stable-contract",
199
+ "kind": "architecture",
200
+ "severity": "block",
201
+ "statement": "Preserve the selected model's public contract.",
202
+ "allowed_paths": ["internal/workflow/**"],
203
+ "blocked_paths": ["dist/**"]
204
+ }
205
+ ],
206
+ "change_bounds": {
207
+ "allowed_paths": ["internal/workflow/**"],
208
+ "blocked_paths": [".git/**", ".env*", "dist/**"],
209
+ "require_explicit_approval_outside_allowed": true
210
+ },
211
+ "workflow": {
212
+ "execution_mode": "run",
213
+ "requires_approval_before_mutation": true,
214
+ "requires_validation_before_done": true
215
+ },
216
+ "validation": {
217
+ "acceptance_criteria": [],
218
+ "required_commands": [],
219
+ "evidence_required": ["scope audit confirms only allowed paths changed"]
220
+ },
221
+ "drift_policy": {
222
+ "block_on": [
223
+ "missing_approval",
224
+ "empty_allowed_paths",
225
+ "changed_blocked_path",
226
+ "validation_failed"
227
+ ],
228
+ "warn_on": []
229
+ }
230
+ }
231
+ ```
@@ -0,0 +1,76 @@
1
+ # KKT State Contract
2
+
3
+ Use this when KKT state must survive across layers, turns, or coding agents. The goal is not to store everything in YAML; it is to make handoff state explicit, inspectable, and hard to confuse.
4
+
5
+ Load `schemas.md` only when a full `kkt.yaml`, layer output, or `guardrails.json` shape is needed.
6
+
7
+ ## Persistence Tiers
8
+
9
+ | Tier | Skill | Durable files | Use when |
10
+ | --- | --- | --- | --- |
11
+ | Plan | `kkt` | none by default; optional `.kkt/kkt.yaml` | ordinary work where Markdown artifacts would be overhead. |
12
+ | Model | `kkt-model` | `.kkt/model/<slug>/kkt.yaml`, `intent.md`, `discovery.md`, `model.md`, `guardrails.json` | durable model or decision brief before execution. |
13
+ | Run | `kkt-run` | `.kkt/run/<slug>/kkt.yaml`, imported artifacts, `guardrails.json`, `plan.md`, `progress.md`, `evidence.md`, `notes.md` | completed model should be implemented now without loop state. |
14
+ | Loop | `kkt-loop` | `.kkt/loop/<slug>/kkt.yaml`, layer artifacts, `guardrails.json`, `plan.md`, `progress.md`, `evidence.md`, `notes.md`, `events.jsonl` | long-running or resumable execution. |
15
+
16
+ Durable `.kkt/` paths are rooted at the nearest Git/worktree root. Outside Git, the CLI falls back to the current directory.
17
+
18
+ ## CLI Ownership
19
+
20
+ The `kkt` CLI is the canonical mutation interface for KKT state. Skills should use CLI commands for workspace creation, state reads, artifact recording, guardrails, approvals, progress, evidence, validation, and completion.
21
+
22
+ - `kkt.yaml`: current status, active layer, method choices, decisions, artifact references, approvals, stop conditions, and summaries.
23
+ - Markdown artifacts: detailed intent, discovery, modeling rationale, execution plan, progress, evidence, and notes.
24
+ - `guardrails.json`: modeled constraints, allowed paths, blocked paths, validation requirements, and drift policy.
25
+ - `events.jsonl`: loop-only append history for task transitions, evidence, approvals, blockers, validation, and completion.
26
+
27
+ Do not hand-edit `kkt.yaml` as the primary workflow operation when a CLI command exists.
28
+
29
+ ## Useful Commands
30
+
31
+ ```text
32
+ kkt start plan "<request>"
33
+ kkt start model "<request>"
34
+ kkt run from-model [model-workspace]
35
+ kkt start run "<request>"
36
+ kkt start loop "<request>"
37
+ kkt intent|discovery|model --method <method> "<layer output>"
38
+ kkt guardrails show|set|validate
39
+ kkt judge --checkpoint model-ready|pre-mutation|continuation|finalize --json
40
+ kkt validate [--run]
41
+ kkt done
42
+ ```
43
+
44
+ ## Artifact Boundaries
45
+
46
+ - `intent.md`: user meaning, success, scope, examples, priority signals, explicit constraints, unresolved meaning questions.
47
+ - `discovery.md`: files, symbols, components, workflows, discovered constraints, validation paths, coupling, evidence, confidence, unknowns.
48
+ - `model.md`: method selection, objective, constraints, decision variables, candidates, feasibility, selected plan, binding constraints, validation plan, sensitivity, execution implications, residual risk.
49
+ - `guardrails.json`: machine-readable drift contract; run and loop execution must not proceed when modeled constraints or allowed paths are empty.
50
+ - `plan.md`: execution tasks, acceptance criteria, validation plan, evidence required, stop conditions, continuation policy.
51
+ - `progress.md`: work log, progress narrative, blocker notes.
52
+ - `evidence.md`: validation map, command outputs, artifacts, final certificate.
53
+ - `notes.md`: observations, assumptions, open questions, deferred ideas.
54
+ - `events.jsonl`: append-only loop event history, not a competing source of truth for current state.
55
+
56
+ When `guardrails.json` lists `validation.required_commands`, run or loop workspaces must use `kkt validate --run` to record deterministic command proof. `kkt evidence` records narrative evidence and criterion mapping only.
57
+
58
+ ## Handoff Rules
59
+
60
+ 1. Read `kkt.yaml` first when it exists.
61
+ 2. Read the prior layer's artifact before acting.
62
+ 3. Update only the current layer unless repairing a stale reference.
63
+ 4. Append decisions instead of overwriting prior rationale.
64
+ 5. Set `next_layer_readiness` before handing off.
65
+ 6. Record blockers with the smallest user or system change that would unblock.
66
+ 7. If new evidence invalidates an earlier layer, mark the active layer blocked and re-open the earlier layer instead of silently continuing.
67
+
68
+ ## Judge Checkpoints
69
+
70
+ - `model-ready`: before implementation; blocks run/loop execution when model, guardrails, or allowed path bounds are incomplete.
71
+ - `pre-mutation`: before edits or side effects; blocks when approval is missing or explicitly blocked paths changed; unrelated dirty paths outside allowed bounds are ignored.
72
+ - `continuation`: before loop continuation; blocks on active stop conditions or replay drift.
73
+ - `finalize`: before `kkt done`; blocks when validation fails or explicitly blocked paths changed; unrelated dirty paths outside allowed bounds are ignored.
74
+ - `pre-tool`, `post-tool`, `pre-compact`, `post-compact`: portable hook names for adapters; enforce explicit blocked paths without requiring a clean worktree.
75
+
76
+ Treat `block` as a hard stop. Treat `warn` as a contract-quality issue to repair before risky work. Treat `allow` as permission to continue to the next workflow step.
@@ -0,0 +1,76 @@
1
+ ---
2
+ name: kkt-model
3
+ description: Deep constrained optimization modeling for coding and product-engineering decisions. Use when a coding agent should capture user meaning, discover repo constraints and validation paths, inspect the system, identify objectives, system state, decision variables, domains, hard and soft constraint contracts, selected-plan binding constraints, execution-contract implications, multiple feasible models or architectures, sensitivity analysis, and interactive user tradeoffs before any implementation.
4
+ license: Apache-2.0
5
+ ---
6
+
7
+ # KKT Model
8
+
9
+ Use this skill when the deliverable is a model, decision brief, or implementation-ready recommendation rather than code. It is for architecture choices, feature shaping, complex implementation options, scope negotiation, and high-impact tradeoffs.
10
+
11
+ Read `references/kkt-kernel.md` and `references/feature-optimization-model.md` before acting. Read `references/layered-modeling-methods.md` when choosing methods, which is normal for deep modeling. Read `references/state-contract.md` when durable model state is useful. Read `references/plan-assimilation.md` only when prior plan text exists. Read `references/discovery-tooling.md` during discovery. Read `references/schemas.md` only when writing or auditing full state, guardrail, or layer-output shapes.
12
+
13
+ ## Core Rule
14
+
15
+ Stay non-mutating by default. Intake before modeling. Discovery before asking for repo facts. Select the modeling method that fits the decision shape. Ask only for product, risk, scope, approval, or execution-mode choices that cannot be resolved from inspection or conservative reversible defaults.
16
+
17
+ ## CLI-First Workflow
18
+
19
+ Use the `kkt` CLI whenever durable model state is useful. The skill owns modeling judgment; the CLI owns workspace creation, state reads, artifact recording, validation, and completion.
20
+
21
+ ```text
22
+ kkt start model "<user request>"
23
+ kkt status [--json]
24
+ kkt next
25
+ kkt intent --method <goal_anti_goal|why_how|obstacle_questions|pairwise_questions> "<intent frame>"
26
+ kkt discovery --method <naive|traceability_matrix|coupling_map|dsm_lite> "<repo facts and constraints>"
27
+ kkt model --method <lexicographic|decision_tree|shortest_path|ordinal_mcda|pairwise_ahp|outranking> "<objective_function, files_to_modify, constraint_functions, decision_variables, validation_proof, and selected model>"
28
+ kkt guardrails set '<constraints and path bounds JSON>'
29
+ kkt guardrails validate
30
+ kkt validate
31
+ kkt done
32
+ ```
33
+
34
+ If `kkt` is missing and durable model state is needed, stop and ask the user to install or upgrade KKT. Do not hand-write replacement state.
35
+
36
+ ## Workflow
37
+
38
+ 1. Capture intent: user goal, desired behavior, user-visible success, scope boundary, examples, priority signals, and explicit user constraints.
39
+ 2. If prior plan text exists, assimilate it as untrusted scaffold before modeling: extract signals, classify each claim, verify discoverable facts, and treat unverified claims as assumptions or candidates.
40
+ 3. Run the interactive intent checkpoint before deep discovery: after any quick inspection needed to avoid asking repo-fact questions, ask 1-3 owner-decision questions when goal, success, scope, risk, or tradeoff preference is still ambiguous. For large, high-risk, or especially ambiguous work, run a short Socratic pass using WHY/HOW, obstacle, example/counterexample, or pairwise tradeoff prompts.
41
+ 4. Inspect relevant code, docs, configs, schemas, routes, tests, UI, infra, issues, or logs before choosing a model. Use `rg` directly for broad text and file discovery, `ast-grep` directly for structural search when syntax matters, `git` for repository state, optional helpers and language-native commands when they provide stronger evidence.
42
+ 5. Separate explicit requirements, prior-plan assumptions, discovered facts, inferred constraints, assumptions, unknowns, and owner decisions.
43
+ 6. Build a discovery map when the decision crosses modules, workflows, contracts, or architecture boundaries.
44
+ 7. Select one intent method, one discovery method, and one modeling method from the layered catalog; record each with the matching `kkt ... --method` command. When no specialized method fits, use the fallback set (`goal_anti_goal`, `traceability_matrix`, `lexicographic`) and record why the fallback is sufficient instead of forcing an advanced method.
45
+ 8. Build the shared optimization model from intent and discovery: objective function, system state, files to modify or affected surfaces, constraint functions, decision variables, hard/soft constraints, candidates, feasibility, binding constraints, sensitivity, and execution implications.
46
+ 9. Produce 2-4 candidate models when meaningful alternatives exist; eliminate infeasible models before comparing feasible ones.
47
+ 10. Compare feasible models by hard-constraint satisfaction, binding constraints, blast radius, maintainability, validation clarity, reversibility, and fit with user intent.
48
+ 11. Ask the user only for unresolved owner decisions; otherwise select the best feasible model.
49
+ 12. Translate the selected model into guardrail variables: constraints, allowed paths, blocked paths, validation evidence, and required commands.
50
+ 13. Record durable output with `kkt intent --method`, `kkt discovery --method`, `kkt model --method`, `kkt guardrails set`, `kkt guardrails validate`, and `kkt validate` when a workspace exists.
51
+
52
+ ## End States
53
+
54
+ End with one of:
55
+
56
+ - `Selected model`: one feasible model is recommended and ready for implementation.
57
+ - `Decision needed`: the smallest user decisions required to select a model.
58
+ - `No feasible model`: the hard constraints that block feasibility and the relaxation that would restore it.
59
+
60
+ For each serious alternative, include the method used, objective fit, decision-variable assignments, hard-constraint status, binding constraints, tradeoffs, execution-contract implications, residual risks, and when to choose it.
61
+
62
+ Decision briefs must include the optimized-plan reasoning from `references/feature-optimization-model.md`: objective function, known constraints, files to modify or affected surfaces, forbidden files or surfaces, constraint functions, decision variables, candidate feasibility, selected plan, binding constraints, validation proof, execution implications, and residual risk.
63
+
64
+ ## Durable Output
65
+
66
+ For substantial modeling work, use project-root `.kkt/model/<slug>/` through `kkt` commands. `kkt.yaml` is the state index; Markdown files carry rich intent, discovery, and modeling context. `guardrails.json` carries the modeled constraints and path bounds that `$kkt-run` or `$kkt-loop` will enforce before mutation. Load `references/schemas.md` only when a full copyable shape is needed. Do not create execution files unless switching to `$kkt-run` or `$kkt-loop`.
67
+
68
+ ## Do Not
69
+
70
+ - Do not modify code unless the user explicitly switches from modeling to implementation.
71
+ - Do not invent numeric scores for subjective criteria.
72
+ - Do not collapse materially different architectures into one vague plan.
73
+ - Do not ask for user input before inspecting discoverable context.
74
+ - Do not choose a method because it sounds rigorous; choose it because the decision shape calls for it.
75
+ - Do not recommend a model without selected-plan binding constraints and execution implications.
76
+ - Do not finish a durable model without guardrail constraints and non-empty allowed paths.
@@ -0,0 +1,53 @@
1
+ # Discovery Tooling
2
+
3
+ Use this during discovery to prove repo facts accurately with direct agent tool calls.
4
+
5
+ ## Rule
6
+
7
+ Use the lightest reliable tool that can prove the needed fact. Start with `rg` for broad text/file discovery, then use `ast-grep` for structural questions. Prefer exact, inspectable evidence over broad inference. Record important negative searches when they shape the model.
8
+
9
+ Discovery tools are read-only during planning and modeling. Rewrite, update, or codegen modes belong to approved execution.
10
+
11
+ Do not route discovery through `kkt` CLI commands. The CLI owns deterministic workflow state; the agent owns repo inspection.
12
+
13
+ ## Tool Ladder
14
+
15
+ - Core: `git` for repository boundary, tracked files, status, diffs, history, and changed-path scope.
16
+ - Core: `rg` for strings, filenames, config keys, docs, tests, shell scripts, and negative searches.
17
+ - Core structural: `ast-grep` for syntax-aware search when call sites, imports, handlers, declarations, components, error handling, or API shapes matter.
18
+ - Optional: `fd`, `ctags`, `tokei`, `scc`, and repo-native commands when they add confidence.
19
+ - Language-native: `go list`, `go test`, `cargo metadata`, `npm` scripts, `tsc`, `pytest --collect-only`, Gradle, Maven, Rails, Django, or equivalent repo tooling.
20
+
21
+ ## Selection Rules
22
+
23
+ - Use `git ls-files` or `rg --files` before broad recursive scans.
24
+ - Use `rg` for text and file discovery.
25
+ - Use `ast-grep` when syntax matters and text evidence would be noisy or ambiguous.
26
+ - Use language-native tooling for package boundaries, route maps, type contracts, test commands, or generated-code boundaries.
27
+ - If `ast-grep` is unavailable, record the setup gap and fall back only as far as the evidence supports. Do not claim AST-level certainty from text search alone.
28
+
29
+ ## Ast-Grep Policy
30
+
31
+ Allowed during discovery:
32
+
33
+ ```text
34
+ ast-grep --pattern '<pattern>' --lang <language>
35
+ ast-grep --pattern '<pattern>' --lang <language> --json
36
+ ast-grep scan --config sgconfig.yml --json
37
+ ```
38
+
39
+ Forbidden during planning or modeling:
40
+
41
+ ```text
42
+ ast-grep --rewrite ...
43
+ ast-grep scan --update-all
44
+ ast-grep scan --interactive
45
+ ```
46
+
47
+ Rewrites require the execution layer, approval, and normal KKT guardrails.
48
+
49
+ ## Guardrails
50
+
51
+ - Do not add a KKT discovery command as a substitute for direct `rg` and `ast-grep` use.
52
+ - Do not claim structural certainty from plain text search when AST search or language-native tools are needed and available.
53
+ - Do not use generated, vendored, or build-output files as primary evidence unless the task explicitly targets them.
@@ -0,0 +1,120 @@
1
+ # Feature Optimization Model
2
+
3
+ Use this reference when building or reviewing a KKT model. Keep the active model compact; load `schemas.md` only when a full copyable shape is needed.
4
+
5
+ ## Intake
6
+
7
+ Start with user meaning, then let discovery fill in repo facts.
8
+
9
+ Capture:
10
+
11
+ - user goal;
12
+ - desired behavior;
13
+ - user-visible success;
14
+ - scope boundary;
15
+ - examples or counterexamples, if supplied;
16
+ - priority signals;
17
+ - explicit user constraints;
18
+ - execution mode: `implement`, `model_only`, `run`, or `loop`.
19
+
20
+ When prior plan text exists, read `plan-assimilation.md` first. Preserve the user's original request, classify prior-plan claims, verify discoverable facts, and keep unverified claims as assumptions or candidates.
21
+
22
+ Do not ask the user for repo facts that local discovery can verify. Use the question filter in `kkt-kernel.md`.
23
+
24
+ ## Model Shape
25
+
26
+ Treat the task as:
27
+
28
+ ```text
29
+ choose implementation decisions
30
+ that best satisfy the user's objective
31
+ subject to project, architecture, security, data, UI, infrastructure, validation, and scope constraints
32
+ ```
33
+
34
+ Build the model around:
35
+
36
+ - `objective_function`: ordered terms used to compare feasible plans.
37
+ - `system_state`: inspected facts plus labeled assumptions.
38
+ - `decision_variables`: choices the agent may make, each with an allowed domain.
39
+ - `files_to_modify`: expected files, modules, APIs, workflows, migrations, docs, or operational surfaces.
40
+ - `constraint_contract`: hard predicates for feasibility and soft preferences for ranking.
41
+ - `feasible_region`: candidate plans that satisfy all hard constraints.
42
+ - `selected_plan`: chosen feasible plan and why it wins.
43
+ - `binding_constraints`: active constraints that shape the selected plan.
44
+ - `validation_proof`: commands, checks, artifacts, or explicit limitations needed before completion.
45
+
46
+ ## Method Profiles
47
+
48
+ - Plan profile (`kkt`): compact intake, local discovery, hard-constraint feasibility, lexicographic ranking, approval before edits, validation certificate.
49
+ - Deep profile (`kkt-model`): layered method selection, candidate comparison, binding constraints, sensitivity, guardrail variables, and user tradeoff questions when needed.
50
+ - Run profile (`kkt-run`): import a completed model, validate guardrails, run deterministic checkpoints, execute only the selected plan.
51
+ - Loop profile (`kkt-loop`): durable model plus continuation state, task/criteria tracking, evidence-backed continuation, and re-optimization only on material new evidence.
52
+
53
+ Read `layered-modeling-methods.md` for deep or loop modeling choices. Do not expose formal method names in ordinary `$kkt` output unless they explain a material tradeoff.
54
+
55
+ ## Decision Variables
56
+
57
+ Decision variables are implementation choices with explicit domains. Common variables include:
58
+
59
+ - files or modules to modify;
60
+ - endpoint, CLI, schema, or event shape;
61
+ - data storage or migration strategy;
62
+ - state ownership;
63
+ - UI placement;
64
+ - validation strategy;
65
+ - compatibility strategy;
66
+ - dependency strategy;
67
+ - rollout or fallback strategy.
68
+
69
+ Poor: `database: decide storage`
70
+
71
+ Better: `persistence_strategy: add nullable fields to existing table`, with allowed and disallowed options recorded.
72
+
73
+ ## Constraints
74
+
75
+ Hard constraints make a plan infeasible when violated:
76
+
77
+ - explicit user constraints and non-goals;
78
+ - correctness, security, privacy, and data integrity;
79
+ - public API or persisted-data compatibility;
80
+ - framework, runtime, infrastructure, or deployment limits;
81
+ - no destructive action, credentials, paid services, or external side effects without approval.
82
+
83
+ Soft constraints rank feasible plans:
84
+
85
+ - minimal diff and blast radius;
86
+ - existing style and architecture fit;
87
+ - readability, maintainability, reversibility, and validation clarity.
88
+
89
+ Use lexicographic priority instead of fake numeric scores:
90
+
91
+ 1. Satisfy the user request.
92
+ 2. Preserve correctness, security, data integrity, and public contracts.
93
+ 3. Minimize blast radius.
94
+ 4. Match existing architecture and conventions.
95
+ 5. Improve maintainability where cheap.
96
+ 6. Prefer validation clarity over elegance.
97
+
98
+ ## Selected Plan Contract
99
+
100
+ An approval-ready plan or selected model must include:
101
+
102
+ - objective function;
103
+ - known constraints by source: explicit, discovered, inferred, assumptions;
104
+ - decision variables and chosen values;
105
+ - affected files or surfaces;
106
+ - feasible and rejected candidates;
107
+ - selected plan;
108
+ - binding constraints;
109
+ - validation plan and proof required;
110
+ - execution implications;
111
+ - guardrail variables when durable run or loop state will enforce scope;
112
+ - residual risk.
113
+
114
+ If a field is irrelevant, say `none` or give a short reason. Do not hide constraints inside prose.
115
+
116
+ ## Re-Optimization
117
+
118
+ Re-optimize when new evidence changes system state, feasible region, hard constraints, selected-plan binding constraints, selected decisions, or validation feasibility.
119
+
120
+ Do not re-optimize merely because another plan feels more elegant.
@@ -0,0 +1,58 @@
1
+ # KKT Kernel
2
+
3
+ This is the mandatory operating contract for every KKT skill. It should stay short enough to read on every invocation.
4
+
5
+ ## Invariants
6
+
7
+ - Capture user meaning before modeling.
8
+ - Discover repo facts before asking the user for file names, routes, schemas, tests, commands, or config.
9
+ - Treat prior host-agent or plan-mode output as scaffold, not truth.
10
+ - Check hard constraints before comparing plans.
11
+ - Pick the smallest feasible plan that satisfies the user's objective and protects existing contracts.
12
+ - Get approval before mutation when the skill is in a planning, model, run, or loop gate.
13
+ - Validate with evidence before completion.
14
+ - Re-optimize only when new evidence changes facts, constraints, feasible plans, selected decisions, or validation feasibility.
15
+
16
+ ## Question Filter
17
+
18
+ Before asking, classify the unknown:
19
+
20
+ - `discoverable_fact`: inspect the repo, docs, tests, config, schemas, routes, logs, or issues.
21
+ - `reversible_default`: choose the conservative low-risk default and label it as an assumption.
22
+ - `owner_decision`: ask when the answer changes product behavior, scope, risk, approval, destructive actions, external dependencies, credentials, paid services, or execution mode.
23
+ - `blocking_unknown`: stop when no conservative default keeps the hard constraints feasible.
24
+
25
+ ## Core Model
26
+
27
+ Every KKT model or approval-ready plan needs:
28
+
29
+ - objective function;
30
+ - known constraints, with explicit, discovered, inferred, and assumed sources separated;
31
+ - decision variables with allowed domains and chosen values;
32
+ - files, modules, APIs, workflows, docs, migrations, or operational surfaces expected to change;
33
+ - candidate plans, with infeasible options rejected before comparison;
34
+ - selected feasible plan and why it dominates alternatives;
35
+ - binding constraints that shaped the selected plan;
36
+ - validation plan and evidence required;
37
+ - residual risk.
38
+
39
+ ## Discovery Rules
40
+
41
+ - Use `git` for repository boundaries, status, diffs, history, and changed-path scope.
42
+ - Use `rg` immediately for broad text and file discovery.
43
+ - Use `ast-grep` immediately when syntax matters and text search would be ambiguous.
44
+ - Use language-native tools when they reveal package boundaries, types, route maps, generated-code boundaries, or test contracts.
45
+ - If `ast-grep` is unavailable in an already-installed environment, record the setup gap and do not claim AST-level certainty from text search alone.
46
+ - Record important negative searches when they shape the selected plan.
47
+
48
+ ## Completion Certificate
49
+
50
+ Finish with:
51
+
52
+ ```text
53
+ Objective: satisfied / not satisfied
54
+ Hard constraints: satisfied / violations listed
55
+ Binding constraints: respected / changed
56
+ Validation evidence: commands, checks, artifacts, or reason validation was not possible
57
+ Residual risk: concise notes
58
+ ```