stop-wasting-tokens 1.0.0 → 1.5.2
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.
- package/CONTRIBUTING.md +78 -0
- package/LICENSE +21 -0
- package/README.md +340 -6
- package/SECURITY.md +57 -0
- package/dist/cli.d.ts +51 -0
- package/dist/cli.mjs +55691 -0
- package/dist/cli.mjs.map +1 -0
- package/package.json +82 -11
package/CONTRIBUTING.md
ADDED
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Contributing to stop-wasting-tokens
|
|
2
|
+
|
|
3
|
+
Thanks for considering a contribution. The project is in early alpha and the surface is changing quickly, so please open an issue before starting non-trivial work.
|
|
4
|
+
|
|
5
|
+
## Code of Conduct
|
|
6
|
+
|
|
7
|
+
All participation is governed by the [Code of Conduct](CODE_OF_CONDUCT.md).
|
|
8
|
+
|
|
9
|
+
## Beta tester
|
|
10
|
+
|
|
11
|
+
The v0.1.0-alpha closed beta is live. If you want to help shape v1.0:
|
|
12
|
+
|
|
13
|
+
- Read the [beta tester guide](https://docs.stopwastingtokens.dev/recipes/beta-feedback) — it covers install, what to test, and how to report what you find.
|
|
14
|
+
- File [friction reports](.github/ISSUE_TEMPLATE/friction.md) — even subtle "this should be smoother" feedback is signal.
|
|
15
|
+
- Join the closed-beta Discord (invite via DM during the beta window).
|
|
16
|
+
- Optionally enable anonymous telemetry: `swt config set telemetry.enabled true`.
|
|
17
|
+
|
|
18
|
+
Top-10 friction items will be addressed before v1.0 release.
|
|
19
|
+
|
|
20
|
+
## Reporting issues
|
|
21
|
+
|
|
22
|
+
- **Bug:** use the bug template under `.github/ISSUE_TEMPLATE/`. Include reproduction steps, expected vs actual behaviour, your Node version, OS, and Codex CLI version.
|
|
23
|
+
- **Feature request:** use the feature template. Describe the use case before the proposed solution.
|
|
24
|
+
- **Question:** use the question template, or join the discussion forum (link TBD once the docs site is live).
|
|
25
|
+
|
|
26
|
+
## Pull requests
|
|
27
|
+
|
|
28
|
+
1. Fork the repo, create a branch from `main` (e.g. `feat/something`, `fix/something`).
|
|
29
|
+
2. Make your changes. Keep PRs focused — one logical change per PR.
|
|
30
|
+
3. Run the project's checks locally before pushing:
|
|
31
|
+
```
|
|
32
|
+
pnpm install
|
|
33
|
+
pnpm typecheck
|
|
34
|
+
pnpm lint
|
|
35
|
+
pnpm test
|
|
36
|
+
```
|
|
37
|
+
These commands are wired up starting in Phase 2 (Foundation).
|
|
38
|
+
4. Add a Changeset entry: `pnpm changeset` and follow the prompts.
|
|
39
|
+
5. Open the PR using the [pull request template](.github/PULL_REQUEST_TEMPLATE.md).
|
|
40
|
+
6. CI must pass before review. Maintainers will request changes via review comments.
|
|
41
|
+
|
|
42
|
+
## Commit conventions
|
|
43
|
+
|
|
44
|
+
This project follows [Conventional Commits](https://www.conventionalcommits.org/). Examples:
|
|
45
|
+
|
|
46
|
+
- `feat(cli): add swt status command`
|
|
47
|
+
- `fix(codex-driver): handle empty hooks.json`
|
|
48
|
+
- `docs(readme): clarify install instructions`
|
|
49
|
+
- `chore(deps): bump tsup to 8.x`
|
|
50
|
+
|
|
51
|
+
The commit type drives Changesets release notes, so please use the right type.
|
|
52
|
+
|
|
53
|
+
## Originality and licensing of contributions
|
|
54
|
+
|
|
55
|
+
By submitting a contribution you confirm that:
|
|
56
|
+
|
|
57
|
+
1. The work is your own, or you have the right to submit it under the project's license.
|
|
58
|
+
2. You agree that your contribution is licensed under the same MIT license as the rest of the project (see [LICENSE](LICENSE)).
|
|
59
|
+
3. You have not copied source code from any third-party project that is not compatibly licensed.
|
|
60
|
+
|
|
61
|
+
If a contribution is inspired by published documentation, blog posts, or open-source projects, please cite the source in the PR description.
|
|
62
|
+
|
|
63
|
+
## Development environment
|
|
64
|
+
|
|
65
|
+
- **Node:** 20.18+ or 22.x.
|
|
66
|
+
- **Package manager:** pnpm (workspaces are used from Phase 2 onward).
|
|
67
|
+
- **Editor:** any. We ship `.vscode/settings.json` recommendations once Phase 2 lands.
|
|
68
|
+
- **OS:** Linux, macOS, and Windows are all supported. Please report platform-specific issues against the bug template.
|
|
69
|
+
|
|
70
|
+
## Releasing
|
|
71
|
+
|
|
72
|
+
Maintainer-only. Releases are cut via the Changesets release workflow. See `docs/releasing.md` (added in Phase 9) for the full procedure.
|
|
73
|
+
|
|
74
|
+
## Getting help
|
|
75
|
+
|
|
76
|
+
- Open a question issue for project-related questions.
|
|
77
|
+
- For ad-hoc design discussion, the discussion forum is the best venue (link TBD).
|
|
78
|
+
- For private maintainer contact, see [SECURITY.md](SECURITY.md).
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Tiago Serôdio (@yidakee) and SWT contributors
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
package/README.md
CHANGED
|
@@ -1,15 +1,349 @@
|
|
|
1
|
-
#
|
|
1
|
+
# stop-wasting-tokens
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
[](https://www.npmjs.com/package/stop-wasting-tokens)
|
|
4
|
+
[](https://github.com/swt-labs/stop-wasting-tokens/actions/workflows/ci.yml)
|
|
5
|
+
[](LICENSE)
|
|
6
|
+
|
|
7
|
+
> A spec-driven harness for the OpenAI Codex CLI, built around a single obsession: **stop wasting tokens**.
|
|
8
|
+
|
|
9
|
+
`swt` is a Node/TypeScript CLI you install once. It wraps every Codex session in a six-agent software development lifecycle, persistent planning artefacts, and goal-backward verification — so the model never re-discovers what you already specified, never improvises past a documented plan, and never burns turns on work the spec doesn't ask for.
|
|
10
|
+
|
|
11
|
+
If you've ever watched Codex re-read your codebase three times in one session, hallucinate an architecture you already rejected, or chase a fix in circles because the goal drifted mid-stream — that's the waste this tool is engineered to eliminate.
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Table of contents
|
|
16
|
+
|
|
17
|
+
- [What "saving tokens" actually means](#what-saving-tokens-actually-means)
|
|
18
|
+
- [How SWT works](#how-swt-works)
|
|
19
|
+
- [Prerequisites](#prerequisites)
|
|
20
|
+
- [Install](#install)
|
|
21
|
+
- [Verify the install](#verify-the-install)
|
|
22
|
+
- [Quick start: a real session](#quick-start-a-real-session)
|
|
23
|
+
- [The methodology](#the-methodology)
|
|
24
|
+
- [Configuration](#configuration)
|
|
25
|
+
- [Command reference](#command-reference)
|
|
26
|
+
- [Troubleshooting](#troubleshooting)
|
|
27
|
+
- [Status](#status)
|
|
28
|
+
- [Contributing, security, license](#contributing-security-license)
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## What "saving tokens" actually means
|
|
33
|
+
|
|
34
|
+
Token waste in AI coding has five concrete sources. SWT is designed to attack each one:
|
|
35
|
+
|
|
36
|
+
| Waste source | Without SWT | With SWT |
|
|
37
|
+
| ----------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
|
|
38
|
+
| Re-reading project context every turn | Codex re-greps, re-globs, re-reads files it saw 5 minutes ago | Stable cache-prefix prompts; durable `.swt-planning/` artefacts persist between turns |
|
|
39
|
+
| Re-discovering architecture & decisions | Each session starts cold, re-derives constraints, re-debates trade-offs | `PROJECT.md`, `REQUIREMENTS.md`, `STATE.md` are read once and stay cached for the whole milestone |
|
|
40
|
+
| Improvised approaches that get rejected | Model proposes, you correct, model re-proposes — three turns gone | Plans are written by Architect/Lead **before** Dev gets the keys; rejected approaches are recorded in `ASSUMPTIONS.md` |
|
|
41
|
+
| Goal drift mid-execution | "While I was at it, I also refactored…" — the dreaded scope explosion | Goal-backward QA verifies output against the **specified** plan, not against improvised goals |
|
|
42
|
+
| Re-running QA from scratch on small fixes | Full validation matrix every time | Three QA tiers (`quick` / `standard` / `deep`) plus a `fix` lane that targets only the failed acceptance criterion |
|
|
43
|
+
|
|
44
|
+
Every design decision in SWT — split prompts, pinned model profiles per agent, the phase artefact pipeline, the verification tiers, even the file-locking system — is downstream of "minimize tokens spent per shipped acceptance criterion."
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## How SWT works
|
|
49
|
+
|
|
50
|
+
In one sentence: **you write a spec, SWT turns it into a plan, six specialist agents execute the plan, and a verification stage compares output to the spec before anything ships.**
|
|
51
|
+
|
|
52
|
+
```
|
|
53
|
+
You write SWT turns it into Six agents execute Output is verified
|
|
54
|
+
───────── ───────────────── ────────────────── ─────────────────
|
|
55
|
+
PROJECT.md ROADMAP.md (phases) Scout → research QA tier
|
|
56
|
+
REQUIREMENTS.md PHASE/PLAN.md (tasks) Architect → design Goal-backward
|
|
57
|
+
Lead → coordinate Acceptance criteria
|
|
58
|
+
Dev → implement UAT scenarios
|
|
59
|
+
QA → verify
|
|
60
|
+
Debugger → resolve
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
Each agent has a fixed model profile and reasoning effort tuned for its role (Scout uses `gpt-5.5/low`, Architect uses `gpt-5.5/high`, Dev uses `gpt-5.3-codex/medium`, etc). You don't think about model selection — the methodology does.
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## Prerequisites
|
|
68
|
+
|
|
69
|
+
| Tool | Version | Why |
|
|
70
|
+
| -------------------------------------------- | ------------ | ------------------------------------------------ |
|
|
71
|
+
| **Node.js** | `>= 20.18` | Runtime for the `swt` CLI itself |
|
|
72
|
+
| **OpenAI Codex CLI** | `>= 0.124.0` | The backend SWT orchestrates against |
|
|
73
|
+
| **Git** | any recent | Phase commits, milestone tags, the pre-push hook |
|
|
74
|
+
| One of: **npm 10+**, **pnpm 9+**, **bun 1+** | — | Pick whichever you already use |
|
|
75
|
+
|
|
76
|
+
Optional but recommended:
|
|
77
|
+
|
|
78
|
+
- **`jq`** — used by some helper scripts; `brew install jq` on macOS, `apt install jq` on Linux.
|
|
79
|
+
- **A terminal with 256-color + Unicode support** — `swt watch` renders an Ink TUI dashboard.
|
|
80
|
+
|
|
81
|
+
To check Codex is installed and reachable:
|
|
82
|
+
|
|
83
|
+
```bash
|
|
84
|
+
codex --version
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
If the Codex CLI isn't installed, follow the OpenAI install guide first — SWT is a methodology layer; it doesn't ship its own model runtime.
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Install
|
|
92
|
+
|
|
93
|
+
Install once, globally:
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
# npm
|
|
97
|
+
npm install -g stop-wasting-tokens
|
|
98
|
+
|
|
99
|
+
# pnpm
|
|
100
|
+
pnpm add -g stop-wasting-tokens
|
|
101
|
+
|
|
102
|
+
# bun
|
|
103
|
+
bun add -g stop-wasting-tokens
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
That's it. The package ships an ESM-only bundle with a single `swt` binary. No build step, no peer-dependency negotiation, no native modules.
|
|
107
|
+
|
|
108
|
+
### What the package contains
|
|
109
|
+
|
|
110
|
+
The published tarball is ~1.3 MB compressed and includes:
|
|
111
|
+
|
|
112
|
+
- `dist/cli.mjs` — the bundled CLI (single file, ~2.1 MB)
|
|
113
|
+
- `dist/cli.d.ts` — TypeScript declarations for programmatic consumers
|
|
114
|
+
- `README.md`, `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md`
|
|
115
|
+
|
|
116
|
+
Everything reachable from the CLI entry point is bundled in. There are no transitive runtime dependencies installed alongside.
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Verify the install
|
|
121
|
+
|
|
122
|
+
After install, run:
|
|
123
|
+
|
|
124
|
+
```bash
|
|
125
|
+
swt --version # should print: swt 1.5.1 (or whatever you installed)
|
|
126
|
+
swt --help # should list ~30 commands
|
|
127
|
+
swt doctor # checks: Node version, Codex CLI, jq, git
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
`swt doctor` is the one-shot environmental check. If anything's missing or out-of-version it tells you exactly what to fix.
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## Quick start: a real session
|
|
135
|
+
|
|
136
|
+
This is what a typical first hour with SWT looks like.
|
|
137
|
+
|
|
138
|
+
### 1. Bootstrap a project (`swt init`)
|
|
139
|
+
|
|
140
|
+
In an empty directory or an existing repo:
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
swt init
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
Interactively walks you through:
|
|
147
|
+
|
|
148
|
+
- Confirming or auto-detecting the tech stack (Node? Python? Rust? Mixed?)
|
|
149
|
+
- Naming the project
|
|
150
|
+
- Capturing 3–5 high-level requirements
|
|
151
|
+
- Choosing your defaults: `effort` (`thorough` / `balanced` / `fast` / `turbo`), `autonomy` (`cautious` / `standard` / `confident` / `pure-vibe`), `verification_tier` (`quick` / `standard` / `deep`)
|
|
152
|
+
|
|
153
|
+
Result: a populated `.swt-planning/` directory with `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md`, `STATE.md`, and a `config.json` capturing your defaults.
|
|
154
|
+
|
|
155
|
+
### 2. Map an existing codebase (`swt map`, brownfield only)
|
|
156
|
+
|
|
157
|
+
If you ran `swt init` in an existing repo, follow up with:
|
|
158
|
+
|
|
159
|
+
```bash
|
|
160
|
+
swt map
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
This generates `.swt-planning/codebase/` with `STACK.md`, `ARCHITECTURE.md`, `PATTERNS.md`, `CONCERNS.md` — a dense, cache-friendly snapshot of what's already there. Subsequent agent calls read this once and reference it for the whole milestone instead of re-grepping.
|
|
164
|
+
|
|
165
|
+
### 3. Plan and execute the next phase (`swt vibe`)
|
|
166
|
+
|
|
167
|
+
```bash
|
|
168
|
+
swt vibe
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
`vibe` is the orchestrator. It detects what state you're in (no plan? planned but not built? built but not verified? verified but not archived?) and routes you to the right next step. In the common "fresh project" case:
|
|
172
|
+
|
|
173
|
+
- Spawns **Scout** for ambient research
|
|
174
|
+
- Spawns **Architect** for design decisions
|
|
175
|
+
- Asks you to confirm scope before any code is written
|
|
176
|
+
- Spawns **Lead** to break the phase into atomic tasks
|
|
177
|
+
- Spawns **Dev** to execute each task with one commit per task
|
|
178
|
+
- Spawns **QA** to verify against the goal-backward acceptance criteria
|
|
179
|
+
- Asks you to confirm UAT before declaring the phase complete
|
|
180
|
+
|
|
181
|
+
You can short-circuit to a specific stage with `swt plan`, `swt execute`, `swt qa`, or `swt vibe --plan=03`.
|
|
182
|
+
|
|
183
|
+
### 4. Inspect progress at any time
|
|
184
|
+
|
|
185
|
+
```bash
|
|
186
|
+
swt status # current phase, milestone, % complete
|
|
187
|
+
swt detect-phase --json # machine-readable state (used by the statusline / IDE plugins)
|
|
188
|
+
swt watch # interactive TUI dashboard scoped to the active milestone
|
|
189
|
+
```
|
|
190
|
+
|
|
191
|
+
### 5. Archive a completed milestone
|
|
192
|
+
|
|
193
|
+
When all phases in a milestone pass UAT:
|
|
194
|
+
|
|
195
|
+
```bash
|
|
196
|
+
swt archive
|
|
197
|
+
```
|
|
198
|
+
|
|
199
|
+
Archives `.swt-planning/phases/*` into `.swt-planning/milestones/<NN>-<slug>/`, runs the 7-point pre-archive audit, generates `RELEASE-NOTES.md`, and tags the commit if `auto_push` is configured.
|
|
200
|
+
|
|
201
|
+
### 6. Other common entry points
|
|
202
|
+
|
|
203
|
+
```bash
|
|
204
|
+
swt research "How does feature X interact with Y?" # Scout-only pass; saves to RESEARCH.md
|
|
205
|
+
swt fix "auth flow rejects valid tokens" # quick-fix lane for a single failing UAT scenario
|
|
206
|
+
swt debug "the test in foo.spec.ts fails intermittently" # hypothesis-driven debugging
|
|
207
|
+
swt todo add "investigate caching bug" # add a backlog item to STATE.md
|
|
208
|
+
swt update # check npm for a newer version
|
|
209
|
+
```
|
|
4
210
|
|
|
5
211
|
---
|
|
6
212
|
|
|
7
|
-
|
|
213
|
+
## The methodology
|
|
214
|
+
|
|
215
|
+
### The six agents
|
|
216
|
+
|
|
217
|
+
| Agent | Model profile | Reasoning effort | Job |
|
|
218
|
+
| ------------- | --------------- | ---------------- | ------------------------------------------------------ |
|
|
219
|
+
| **Scout** | `gpt-5.5` | `low` | Ambient research, codebase queries, doc fetches |
|
|
220
|
+
| **Architect** | `gpt-5.5` | `high` | Design decisions, trade-off analysis, scope shaping |
|
|
221
|
+
| **Lead** | `gpt-5.3-codex` | `medium` | Plans phases into atomic tasks; one commit per task |
|
|
222
|
+
| **Dev** | `gpt-5.3-codex` | `medium` | Executes tasks; writes code, tests, docs |
|
|
223
|
+
| **QA** | `gpt-5.3-codex` | `medium` | Goal-backward verification against acceptance criteria |
|
|
224
|
+
| **Debugger** | `gpt-5.3-codex` | `high` | Hypothesis-driven root-cause analysis when QA fails |
|
|
225
|
+
|
|
226
|
+
You can override profiles per-project in `.swt-planning/config.json`, but the defaults are tuned to balance cost, latency, and quality for typical workloads.
|
|
8
227
|
|
|
9
|
-
|
|
228
|
+
### The phase lifecycle
|
|
10
229
|
|
|
11
|
-
|
|
230
|
+
Every phase goes through five states:
|
|
231
|
+
|
|
232
|
+
```
|
|
233
|
+
needs_discussion → needs_plan_and_execute → needs_execute → needs_verification → archived
|
|
234
|
+
(optional) ↑ ↑ ↓
|
|
235
|
+
└──── if user └──── if QA └──── if UAT issues
|
|
236
|
+
rejects scope fails found by user
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
`swt vibe` reads `STATE.md` + on-disk artefacts, computes the current state, and routes to the right command. Manual flags (`--plan`, `--execute`, `--verify`, `--archive`) bypass auto-routing when you want to be explicit.
|
|
240
|
+
|
|
241
|
+
### The artefact pipeline
|
|
242
|
+
|
|
243
|
+
```
|
|
244
|
+
.swt-planning/
|
|
245
|
+
├── PROJECT.md ← what we're building (you write this)
|
|
246
|
+
├── REQUIREMENTS.md ← validated + active + out-of-scope (you write this)
|
|
247
|
+
├── ROADMAP.md ← milestones → phases (Architect generates, you approve)
|
|
248
|
+
├── STATE.md ← current phase, milestone, todos (machine-managed)
|
|
249
|
+
├── config.json ← effort, autonomy, model profiles (you tune)
|
|
250
|
+
├── codebase/ ← brownfield map (swt map output)
|
|
251
|
+
│ ├── STACK.md
|
|
252
|
+
│ ├── ARCHITECTURE.md
|
|
253
|
+
│ ├── PATTERNS.md
|
|
254
|
+
│ └── CONCERNS.md
|
|
255
|
+
├── phases/
|
|
256
|
+
│ └── 01-{slug}/
|
|
257
|
+
│ ├── ASSUMPTIONS.md ← discussion outputs
|
|
258
|
+
│ ├── PLAN.md ← Lead's task breakdown
|
|
259
|
+
│ ├── RESEARCH.md ← Scout's findings
|
|
260
|
+
│ ├── VERIFICATION.md ← QA's contract verification
|
|
261
|
+
│ └── UAT.md ← user acceptance scenarios
|
|
262
|
+
└── milestones/ ← archived phases, frozen
|
|
263
|
+
└── 01-{slug}/
|
|
264
|
+
```
|
|
265
|
+
|
|
266
|
+
Artefacts are read at the **start** of each agent call as part of the cache-stable prefix. Token cost: paid once per file, amortised across every turn in the milestone.
|
|
12
267
|
|
|
13
268
|
---
|
|
14
269
|
|
|
15
|
-
|
|
270
|
+
## Configuration
|
|
271
|
+
|
|
272
|
+
Live config lives in `.swt-planning/config.json` and is editable directly or via `swt config set <key> <value>`.
|
|
273
|
+
|
|
274
|
+
The knobs that matter most:
|
|
275
|
+
|
|
276
|
+
| Key | Values | Default | Effect |
|
|
277
|
+
| ------------------------ | --------------------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
278
|
+
| `effort` | `thorough` / `balanced` / `fast` / `turbo` | `balanced` | Planning depth and verification thoroughness; also a turn-budget scalar (1.5× → 0.6×) applied to every agent |
|
|
279
|
+
| `autonomy` | `cautious` / `standard` / `confident` / `pure-vibe` | `standard` | How aggressively `swt vibe` advances without prompts. `cautious` stops every stage; `pure-vibe` auto-loops everything until a hard error |
|
|
280
|
+
| `verification_tier` | `quick` / `standard` / `deep` | `standard` | What QA runs. `quick` = smoke + lint + types; `standard` = +unit tests + must-have evidence; `deep` = +integration + cross-phase traceability |
|
|
281
|
+
| `model_profile` | `quality` / `balanced` / `cost` | `quality` | Coarse cost/quality switch applied across all six agents |
|
|
282
|
+
| `backend` | `codex` / `claude-code` / `ollama` | `codex` | Which CLI runtime SWT orchestrates against (Codex is fully shipped; Claude Code and Ollama drivers land in v1.6+) |
|
|
283
|
+
| `prefer_teams` | `auto` / `always` / `never` | `auto` | Use parallel agent teams (when supported by your Codex CLI version) |
|
|
284
|
+
| `auto_uat` | `true` / `false` | `false` | When QA passes, auto-route into UAT (`true`) or stop and ask (`false`) |
|
|
285
|
+
| `auto_push` | `never` / `after_phase` / `always` | `never` | When to push commits to `origin` |
|
|
286
|
+
| `planning_tracking` | `manual` / `ignore` / `commit` | `manual` | How `.swt-planning/` interacts with git: `manual` (you decide), `ignore` (gitignored), `commit` (auto-commit at planning checkpoints) |
|
|
287
|
+
| `agent_max_turns.{role}` | int | varies | Per-agent turn cap. Defaults: scout 15, qa 25, architect 30, lead 50, dev 75, debugger 80 |
|
|
288
|
+
| `model_overrides.{role}` | string | none | Override the model for a specific agent (e.g. force the Architect onto a cheaper model for a low-stakes project) |
|
|
289
|
+
|
|
290
|
+
Advanced blocks (not usually edited by hand): `telemetry`, `marketplace`, `hooks`. Run `swt config show` for the full live config.
|
|
291
|
+
|
|
292
|
+
---
|
|
293
|
+
|
|
294
|
+
## Command reference
|
|
295
|
+
|
|
296
|
+
The CLI exposes ~30 commands. The full reference (with examples and flag details) is in [docs.stopwastingtokens.dev](https://docs.stopwastingtokens.dev). Quick index:
|
|
297
|
+
|
|
298
|
+
**Lifecycle** `init` `vibe` `plan` `execute` `verify` `archive`
|
|
299
|
+
**Quality** `qa` `fix` `debug` `audit`
|
|
300
|
+
**Inspection** `status` `detect-phase` `watch` `whats-new`
|
|
301
|
+
**Backlog** `todo` `phase` `assumptions`
|
|
302
|
+
**Research** `research` `discuss`
|
|
303
|
+
**Workspace** `map` `worktree` `lease` `pause` `resume`
|
|
304
|
+
**Maintenance** `doctor` `config` `skills` `update` `uninstall` `release` `version`
|
|
305
|
+
|
|
306
|
+
Every command supports `--help`:
|
|
307
|
+
|
|
308
|
+
```bash
|
|
309
|
+
swt vibe --help
|
|
310
|
+
swt qa --help
|
|
311
|
+
```
|
|
312
|
+
|
|
313
|
+
---
|
|
314
|
+
|
|
315
|
+
## Troubleshooting
|
|
316
|
+
|
|
317
|
+
**`swt: command not found` after install**
|
|
318
|
+
Your global npm bin directory isn't on `PATH`. Run `npm config get prefix` and add `<prefix>/bin` to your shell rc.
|
|
319
|
+
|
|
320
|
+
**`swt --version` reports `0.0.0` after a manual rebuild**
|
|
321
|
+
You're running a locally-built bundle from before the `CURRENT_VERSION` constant was wired up. Reinstall from npm: `npm install -g stop-wasting-tokens`.
|
|
322
|
+
|
|
323
|
+
**`swt vibe` keeps asking the same confirmation**
|
|
324
|
+
Your `autonomy` is set to `cautious` or `standard` (the default). Switch with `swt config set autonomy confident` to auto-chain phases, or `pure-vibe` to auto-loop until a hard error.
|
|
325
|
+
|
|
326
|
+
**Phase detection is in a weird state**
|
|
327
|
+
Run `swt detect-phase` for a JSON dump of what SWT thinks the state is. The `phase_detect_error=true` line points at root cause. As a last resort, `swt pause` saves your in-progress work and lets you restart cleanly.
|
|
328
|
+
|
|
329
|
+
**Codex CLI says it can't find `~/.codex/config.toml [mcp_servers.swt]`**
|
|
330
|
+
The agent TOMLs reference `~/.codex/config.toml` (the documented Codex MCP path). If you're on an older Codex setup that uses `~/.codex/mcp.json`, upgrade Codex (`>= 0.124.0`).
|
|
331
|
+
|
|
332
|
+
**Lots of CI failures right after a push**
|
|
333
|
+
Check whether you're using v1.5.0 or earlier — the build pipeline didn't actually compile until v1.5.1. Update with `npm install -g stop-wasting-tokens@latest`.
|
|
334
|
+
|
|
335
|
+
---
|
|
336
|
+
|
|
337
|
+
## Status
|
|
338
|
+
|
|
339
|
+
Currently shipping **v1.5.1**. v1 milestones (1–15) are complete. v1.5 forward-compatibility is in place for additional backend drivers (Claude Code, Ollama) — see [`docs/roadmap/v1.5.md`](docs/roadmap/v1.5.md). v1 itself targets the Codex CLI only.
|
|
340
|
+
|
|
341
|
+
Per-version changes are tracked in [CHANGELOG.md](CHANGELOG.md). Stable release notes are in [RELEASE-NOTES-v1.0.md](RELEASE-NOTES-v1.0.md).
|
|
342
|
+
|
|
343
|
+
---
|
|
344
|
+
|
|
345
|
+
## Contributing, security, license
|
|
346
|
+
|
|
347
|
+
- Contributions: [CONTRIBUTING.md](CONTRIBUTING.md). Governed by the [Code of Conduct](CODE_OF_CONDUCT.md).
|
|
348
|
+
- Security disclosures: [SECURITY.md](SECURITY.md).
|
|
349
|
+
- License: MIT, see [LICENSE](LICENSE).
|
package/SECURITY.md
ADDED
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Security Policy
|
|
2
|
+
|
|
3
|
+
## Supported versions
|
|
4
|
+
|
|
5
|
+
`stop-wasting-tokens` is currently in alpha. Only the latest published version on the `main` branch is supported. Pre-release versions (`v0.x.y`) may receive fixes only in the most recent release.
|
|
6
|
+
|
|
7
|
+
| Version | Supported |
|
|
8
|
+
| ------------------ | --------- |
|
|
9
|
+
| latest pre-release | Yes |
|
|
10
|
+
| older pre-releases | No |
|
|
11
|
+
|
|
12
|
+
Once the project reaches v1.0, this matrix will be updated to cover at least the current major and the previous major.
|
|
13
|
+
|
|
14
|
+
## Reporting a vulnerability
|
|
15
|
+
|
|
16
|
+
Please **do not** open a public GitHub issue for security reports.
|
|
17
|
+
|
|
18
|
+
Instead, report privately by emailing the maintainer at:
|
|
19
|
+
|
|
20
|
+
> `security@stopwastingtokens.dev` _(placeholder — to be activated when the domain is registered; until then please use GitHub's private "Report a vulnerability" feature on the repository's Security tab)_
|
|
21
|
+
|
|
22
|
+
Include:
|
|
23
|
+
|
|
24
|
+
- A description of the issue and its potential impact.
|
|
25
|
+
- Steps to reproduce, including version numbers, OS, and Codex CLI version.
|
|
26
|
+
- Any proof-of-concept code or commands.
|
|
27
|
+
|
|
28
|
+
## Response process
|
|
29
|
+
|
|
30
|
+
1. We will acknowledge receipt within **72 hours**.
|
|
31
|
+
2. We will provide an initial assessment within **7 days**, including whether we accept the report and a tentative timeline.
|
|
32
|
+
3. We will work on a fix and coordinate disclosure with you. Standard target: a fix released within **90 days** of accepted disclosure.
|
|
33
|
+
4. Once a fix is released, we will publish a security advisory on GitHub crediting you (unless you prefer to remain anonymous).
|
|
34
|
+
|
|
35
|
+
## Scope
|
|
36
|
+
|
|
37
|
+
In scope:
|
|
38
|
+
|
|
39
|
+
- The `stop-wasting-tokens` source code in this repository.
|
|
40
|
+
- Published npm artefacts under the project name.
|
|
41
|
+
- Configuration parsing and command-line argument handling.
|
|
42
|
+
|
|
43
|
+
Out of scope:
|
|
44
|
+
|
|
45
|
+
- Bugs in the OpenAI Codex CLI itself — please report those upstream.
|
|
46
|
+
- Bugs in third-party dependencies — please report those to their respective projects (we will help with coordination if relevant).
|
|
47
|
+
- Issues that require administrative access to a user's machine to exploit.
|
|
48
|
+
|
|
49
|
+
## Safe harbour
|
|
50
|
+
|
|
51
|
+
We will not pursue legal action against researchers who:
|
|
52
|
+
|
|
53
|
+
- Make a good-faith effort to report vulnerabilities through the channel above.
|
|
54
|
+
- Avoid privacy violations, destruction of data, and interruption or degradation of services.
|
|
55
|
+
- Do not exploit a vulnerability beyond what is necessary to demonstrate it.
|
|
56
|
+
|
|
57
|
+
Thank you for helping keep `stop-wasting-tokens` and its users safe.
|
package/dist/cli.d.ts
ADDED
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
declare const EXIT: {
|
|
2
|
+
readonly SUCCESS: 0;
|
|
3
|
+
readonly USAGE_ERROR: 1;
|
|
4
|
+
readonly NOT_IMPLEMENTED: 2;
|
|
5
|
+
};
|
|
6
|
+
type ExitCode = (typeof EXIT)[keyof typeof EXIT];
|
|
7
|
+
|
|
8
|
+
interface ParsedArgv {
|
|
9
|
+
/** First positional argument — the verb (e.g. "config"). */
|
|
10
|
+
readonly verb: string | undefined;
|
|
11
|
+
/** Remaining positional arguments after the verb. */
|
|
12
|
+
readonly positionals: readonly string[];
|
|
13
|
+
/** Parsed flag values keyed by flag name (without the leading --). */
|
|
14
|
+
readonly flags: Readonly<Record<string, string | boolean | undefined>>;
|
|
15
|
+
}
|
|
16
|
+
|
|
17
|
+
interface CommandIO {
|
|
18
|
+
readonly stdout: NodeJS.WritableStream;
|
|
19
|
+
readonly stderr: NodeJS.WritableStream;
|
|
20
|
+
readonly cwd: string;
|
|
21
|
+
}
|
|
22
|
+
type CommandHandler = (parsed: ParsedArgv, io: CommandIO) => Promise<ExitCode> | ExitCode;
|
|
23
|
+
interface CommandSpec {
|
|
24
|
+
readonly name: string;
|
|
25
|
+
readonly description: string;
|
|
26
|
+
readonly handler: CommandHandler;
|
|
27
|
+
/** Optional usage line shown by `swt help`. */
|
|
28
|
+
readonly usage?: string;
|
|
29
|
+
}
|
|
30
|
+
declare class CommandRegistry {
|
|
31
|
+
private readonly commands;
|
|
32
|
+
register(spec: CommandSpec): this;
|
|
33
|
+
get(name: string): CommandSpec | undefined;
|
|
34
|
+
list(): readonly CommandSpec[];
|
|
35
|
+
}
|
|
36
|
+
declare function dispatch(registry: CommandRegistry, parsed: ParsedArgv, io: CommandIO): Promise<ExitCode>;
|
|
37
|
+
|
|
38
|
+
interface MainDeps {
|
|
39
|
+
readonly cwd?: string;
|
|
40
|
+
readonly stdout?: NodeJS.WritableStream;
|
|
41
|
+
readonly stderr?: NodeJS.WritableStream;
|
|
42
|
+
readonly version?: string;
|
|
43
|
+
readonly registry?: CommandRegistry;
|
|
44
|
+
}
|
|
45
|
+
declare function buildRegistry(version?: string): CommandRegistry;
|
|
46
|
+
declare function main(argv?: readonly string[], deps?: MainDeps): Promise<ExitCode>;
|
|
47
|
+
|
|
48
|
+
declare const PACKAGE_NAME = "@swt-labs/cli";
|
|
49
|
+
declare const VERSION = "0.0.0";
|
|
50
|
+
|
|
51
|
+
export { type CommandHandler, type CommandIO, CommandRegistry, type CommandSpec, EXIT, PACKAGE_NAME, VERSION, buildRegistry, dispatch, main };
|