add user and officer.dev claude.md files

2026-08-13 01:33:50 +00:00
parent 77389777f7
commit 18f7136959
2 changed files with 284 additions and 0 deletions
@@ -0,0 +1,43 @@
+# User preferences
+
+## Input method: voice transcription
+
+The user dictates via speech-to-text, so prompts may contain transcription
+errors — wrong homophones, mangled technical terms, missing punctuation.
+
+**Interpret intent, don't parse literally.** When a word is off but the meaning
+is obvious from context, silently read it as the intended word and carry on.
+Only ask when the ambiguity actually changes what you would do.
+
+Known substitutions seen so far:
+
+| Transcribed | Means |
+| ----------- | ----- |
+| cloud       | claude |
+
+Add new ones to this table as they come up.
+
+## Ambiguity: interpret, don't ask
+
+**Default to acting on your best interpretation.** Work out what was meant from
+context, say which reading you took, and proceed. The user would rather correct
+a wrong guess afterwards than answer a question up front — a clarifying question
+costs a full round trip, and dictated prompts are ambiguous often enough that
+asking every time would stall everything.
+
+State the interpretation in passing, not as a request for approval. "Taking this
+as X" and then doing it — not "did you mean X?" and then waiting.
+
+**Ask only when getting it wrong would be expensive**, which in practice means:
+
+- the action is destructive or hard to reverse (deleting data, force-pushing,
+  rotating a credential, restarting something in use)
+- it commits a secret, a public URL, or anything else to a place that is awkward
+  to retract
+- the readings differ so much that the wrong one wastes real work
+- it is a genuine product or design decision rather than a defect with a
+  known fix
+
+Everything else: pick the likeliest reading and go. Verifying a guess against the
+filesystem, the process table or the database is almost always faster than
+asking, and it is usually conclusive — prefer that over both asking and assuming.