feat: add the kettle CLI, replacing the plugin's Python scripts
The plugin resolved its issue store from `__file__`, which put it inside a versioned plugin cache: issues written from one project were invisible from the next, and `origin: local` files — the only copy of that work by definition — were stranded a version bump at a time. The walk that answers "which directory is the project" was written three times over, and in a linked worktree the three disagreed. Both are runtime failures rather than logic ones, so the fix is a compiled binary: one walk, imported rather than re-derived, and a layering rule the build graph enforces instead of a grep. Seven packages, knowledge flowing one way. `project` answers which directory is the project and depends on nothing. `issue` is the domain — format, taxonomy, validation, checkboxes, dependency graph, the store, eviction — offline, with no tracker in it. `wire` holds the protocol shapes. `gitea` is the transport, `mapping` the bridge, `config` the credentials, `cmd` the command tree. Four tests hold the boundaries, each failing on a real mistake rather than a naming convention. The marker moves to `.kettle/` and the login pin moves out of the harness's settings file into `.kettle/config.yaml`, which pins a login by NAME; the tokens live in one file per machine, mode 0600, outside every working tree. That retires the PreToolUse guard hook entirely — the binary holds its own credentials, so a command running under a login nobody chose is not expressible rather than caught. `kettle init` migrates an older `tmp/issues` or `.tea/issues` store in, as a move: a store left behind at an old path is one somebody edits by accident months later. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
naudachu
@@ -0,0 +1,132 @@
|
||||
package issue
|
||||
|
||||
import "strings"
|
||||
|
||||
// The type templates, verbatim from references/format.md.
|
||||
//
|
||||
// Section headers are fixed English literals in a fixed order; body prose is
|
||||
// Russian. Both halves of that rule are in the strings below, and the format
|
||||
// document is the source of truth for them.
|
||||
|
||||
const specSection = "## Spec\nnone\n"
|
||||
|
||||
var templates = map[string]string{
|
||||
"bug": `## Summary
|
||||
Что сломано и где проявляется, одно-два предложения.
|
||||
|
||||
` + specSection + `
|
||||
## Steps to reproduce
|
||||
1. …
|
||||
2. …
|
||||
|
||||
## Expected
|
||||
Что должно было произойти.
|
||||
|
||||
## Actual
|
||||
Что происходит на самом деле: вывод команды, лог.
|
||||
|
||||
## Environment
|
||||
Только релевантное: версии, ОС, конфигурация.
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] баг не воспроизводится по шагам выше
|
||||
- [ ] добавлена проверка на регрессию (если применимо)
|
||||
`,
|
||||
"task": `## Summary
|
||||
Что нужно сделать, одно-два предложения.
|
||||
|
||||
` + specSection + `
|
||||
## Motivation
|
||||
Какую проблему пользователя/системы это решает.
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] проверяемое условие
|
||||
- [ ] …
|
||||
`,
|
||||
"refactor": `## Summary
|
||||
Что перестраиваем и в каких файлах (` + "`path/file:line`" + `).
|
||||
|
||||
` + specSection + `
|
||||
## Motivation
|
||||
Чем плохо текущее состояние: дублирование, связность, читаемость.
|
||||
|
||||
## Invariants
|
||||
Что НЕ должно измениться: поведение, публичные API, форматы данных.
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] проверяемое условие (тесты зелёные, старый путь удалён, …)
|
||||
`,
|
||||
"test": `## Summary
|
||||
Что покрываем тестами и где (` + "`path/file:line`" + `).
|
||||
|
||||
` + specSection + `
|
||||
## Motivation
|
||||
Зачем: регрессия после бага, пробел в покрытии, флаки-тест.
|
||||
|
||||
## Test cases
|
||||
- сценарий → ожидаемый результат
|
||||
- …
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] перечисленные кейсы покрыты и зелёные
|
||||
- [ ] тесты проходят в CI
|
||||
`,
|
||||
"feature": `## Summary
|
||||
Бизнес-ценность одним-двумя предложениями.
|
||||
|
||||
` + specSection + `
|
||||
## Motivation
|
||||
Какую проблему пользователя/системы это решает.
|
||||
|
||||
## Issues
|
||||
- [ ] slug-дочернего-issue — краткое описание части
|
||||
- [ ] …
|
||||
|
||||
## Acceptance criteria
|
||||
- [ ] все дочерние issues закрыты
|
||||
- [ ] проверяемое условие уровня фичи
|
||||
`,
|
||||
"draft": `## Summary
|
||||
Идея одним-двумя предложениями.
|
||||
|
||||
` + specSection + `
|
||||
## Notes
|
||||
Свободные заметки: что известно, открытые вопросы, варианты.
|
||||
`,
|
||||
}
|
||||
|
||||
// Template is the prefilled body for a type, with `## Depends on` inserted
|
||||
// right after `## Spec` when the issue has dependencies.
|
||||
func Template(typ string, depends []string) string {
|
||||
return withDepends(templates[typ], depends)
|
||||
}
|
||||
|
||||
// withDepends places the section where the format says it goes: after
|
||||
// `## Spec`, before everything else. Appended at the end only when the
|
||||
// template has no third section to sit in front of.
|
||||
func withDepends(body string, depends []string) string {
|
||||
if len(depends) == 0 {
|
||||
return body
|
||||
}
|
||||
var b strings.Builder
|
||||
b.WriteString("## Depends on\n")
|
||||
for _, d := range depends {
|
||||
b.WriteString("- " + d + "\n")
|
||||
}
|
||||
block := b.String()
|
||||
|
||||
var out []string
|
||||
placed := false
|
||||
for _, line := range strings.SplitAfter(body, "\n") {
|
||||
if !placed && len(out) > 0 && strings.HasPrefix(line, "## ") &&
|
||||
!strings.HasPrefix(line, SummarySection) && !strings.HasPrefix(line, SpecSection) {
|
||||
out = append(out, block+"\n")
|
||||
placed = true
|
||||
}
|
||||
out = append(out, line)
|
||||
}
|
||||
if !placed {
|
||||
out = append(out, "\n"+block)
|
||||
}
|
||||
return strings.Join(out, "")
|
||||
}
|
||||
Reference in New Issue
Block a user