Initial commit: tungsten's memory tree

1 files changed, 19 insertions, 0 deletions

diff --git a/feedback_commit_as_default.md b/feedback_commit_as_default.md
new file mode 100644
index 0000000..f17c3ac
--- /dev/null
+++ b/feedback_commit_as_default.md
@@ -0,0 +1,19 @@
+---
+name: feedback-commit-as-default
+description: "On the doot project, commit completed work as a normal part of finishing it -- don't wait for an explicit per-instance ask to commit"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 2607e018-d4ad-4ec6-bb68-5f1d0f9a3906
+---
+
+**Commit finished, verified work without waiting to be asked each time.** The global harness default is "never commit unless explicitly asked" -- the user overrode that for this project on 2026-08-04: "committing shouldn't be something I have to ask explicitly for, it should be part of the process." Treat "the fix is done and verified" as sufficient trigger to commit it, the way a competent engineer commits their own completed work without narrating a request for permission each time.
+
+**Why:** Said directly, sharply, after a session where a real production fix sat uncommitted at the end of a long incident-response conversation and the user had to explicitly say "commit your damn work." The friction of re-asking every single time is exactly what they're rejecting.
+
+**How to apply:**
+- Once a change is built, tested, and (for this project) deployed/live-verified, commit it as the natural last step -- don't present "done" and wait for a commit request.
+- Still use judgment on commit boundaries: split unrelated concerns into separate commits (e.g. a Go server fix vs. an Android app fix are different deploy targets/concerns -- kept as two commits in the 2026-08-04 incident response), and write real commit messages explaining why, not just what.
+- This does NOT mean commit everything sitting in the tree indiscriminately -- unrelated in-progress/uncertain work (e.g. a stashed WIP feature from a prior session) should stay uncommitted until its own owner is confident it's done; committing someone's half-finished experiment because "commit by default" is a misapplication of this rule. Ask if genuinely unsure whether something is finished vs. still WIP.
+- The global git-safety rules (never force-push, never skip hooks, never amend without being asked, review staged content for secrets before committing) still apply in full -- this override is specifically about the "ask before every commit" gate, not about commit safety practices generally.
+- Related: [[feedback-verify-before-asserting-root-cause]] -- both pieces of feedback landed in the same session, both about closing the gap between "looks done" and "is actually, verifiably done."