toga-ai 1.0.58 → 1.0.59

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "toga-ai",
3
- "version": "1.0.58",
3
+ "version": "1.0.59",
4
4
  "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
5
5
  "keywords": [
6
6
  "claude",
@@ -7,7 +7,9 @@ description: End-of-session knowledge writer for TOGA Technology projects. Run t
7
7
 
8
8
  You are the **only** editor of the knowledge base; developers never hand-edit it. So you
9
9
  must keep everything consistent and **ask whenever a required fact is missing — never
10
- assume**. Nothing is written until the developer approves your proposal.
10
+ assume**. Routine writes (CREATE / UPDATE / DELETE of non-elevated docs) are applied without
11
+ asking; you pause for approval only on ⚠ ELEVATED docs or genuinely ambiguous placement
12
+ (see Step 4).
11
13
 
12
14
  ### Contribution model
13
15
 
@@ -155,9 +157,18 @@ UPDATE 2.0/apps/worker2/features/creating-worker-actions.md (add files: + gotch
155
157
  DELETE 2.0/apps/worker2/features/old-thing.md (removed this session)
156
158
  ```
157
159
 
158
- Ask the developer to approve. They may accept all, accept some, or edit. **Write nothing
159
- until they confirm.** If a needed placement detail is ambiguous (which client? new vs.
160
- update?), ask before proposing.
160
+ **Auto-apply by default do not ask.** For ordinary CREATE, UPDATE, and DELETE/DEPRECATE of
161
+ **non-elevated** docs, just make the changes and report them in Step 7. Do not present a plan
162
+ and wait for approval — stopping to confirm routine knowledge writes only adds friction.
163
+
164
+ **Confirm first only when:**
165
+ - the change touches a **⚠ ELEVATED** doc (`architecture` / `standard`, senior-owned), or
166
+ - the correct placement is **genuinely ambiguous** (which client? new vs. update? which of
167
+ several candidate docs owns this?).
168
+
169
+ In those two cases, show the short, scannable, framework+repo-qualified plan and the proposed
170
+ content/diffs, and **write nothing until the developer confirms.** They may accept all, accept
171
+ some, or edit. Everywhere else, proceed without asking.
161
172
 
162
173
  ## Step 5 — Apply approved changes (write to TEAM_REPO, not .claude/)
163
174