style: strengthen constructor naming and Params struct rules (#19)

Per sneak's instruction:

- Constructors **must** be `New()`, `From<Something>()`, or `NewThing()` (multi-type packages only)
- Strongly discourage creative names (`Create`, `Make`, `Build`, `Init`)
- Constructors **must** use a `Params` struct (or `ThingParams`) for 2+ arguments — no exceptions
- Single obvious argument (`ctx`, bytes) is the only exception
- `context.Context` does not count against the argument limit (already documented)

Co-authored-by: user <user@Mac.lan guest wan>
Co-authored-by: clawbot <clawbot@noreply.git.eeqj.de>
Reviewed-on: #19
Co-authored-by: clawbot <clawbot@noreply.example.org>
Co-committed-by: clawbot <clawbot@noreply.example.org>

prompts/CODE_STYLEGUIDE_GO.md

@@ -1,6 +1,6 @@
 ---
 title: Code Styleguide — Go
-last_modified: 2026-02-22
+last_modified: 2026-03-18
 ---
 
 1.  Try to hard wrap long lines at 77 characters or less.
@@ -136,8 +136,15 @@ last_modified: 2026-02-22
 1.  Provide a .gitignore file that ignores at least `*.log`, `*.out`, and
     `*.test` files, as well as any binaries.
 
-1.  Constructors should be called `New()` whenever possible. `modulename.New()`
+1.  Constructors **must** be called `New()`. `modulename.New()` works great if
-    works great if you name the packages properly.
+    you name the packages properly. If the constructor creates an instance from
+    an existing value or representation, `From<Something>()` (e.g.
+    `FromBytes()`, `FromConfig()`) is also acceptable. If the package contains
+    multiple types and `New()` is ambiguous, `NewThing()` is occasionally
+    acceptable — but prefer restructuring packages so each type gets its own
+    package and a plain `New()`. Do not invent creative constructor names like
+    `Create()`, `Make()`, `Build()`, `Open()` (unless wrapping an OS resource),
+    or `Init()`. If you see a constructor with a non-standard name, rename it.
 
 1.  Don't make packages too big. Break them up.
 
@@ -149,9 +156,15 @@ last_modified: 2026-02-22
 1.  Use descriptive names for modules and filenames. Avoid generic names like
     `server`. `util` is banned.
 
-1.  Constructors should take a Params struct if they need more than 1-2
+1.  Constructors **must** take a `Params` struct (or `ThingParams` when
-    arguments. Positional arguments are an endless source of bugs and should be
+    `NewThing()` is used), even for a single argument. Named fields in a Params
-    avoided whenever possible.
+    struct are always clearer than positional arguments. Positional arguments
+    for constructors are an endless source of bugs — they make call sites
+    unreadable, invite wrong-order errors that the compiler can't catch when
+    types coincide, and force every caller to update when a new field is added.
+    The only exception is when the single argument is stupidly obvious from
+    context — e.g. `featureflag.New(true)` or `thing.NewFromReader(r)`. When in
+    doubt, use a Params struct.
 
 1.  Use `context.Context` for all functions that need it. If you don't need it,
     you can pass `context.Background()`. Anything long-running should get and

prompts/EXISTING_REPO_CHECKLIST.md

@@ -1,6 +1,6 @@
 ---
 title: Existing Repo Checklist
-last_modified: 2026-02-22
+last_modified: 2026-03-10
 ---
 
 Use this checklist when beginning work in a repo that may not yet conform to our
@@ -78,6 +78,22 @@ with your task.
       `internal/`, `static/`, etc.)
 - [ ] Go migrations in `internal/db/migrations/` and embedded in binary
 
+# HTTP Service Hardening (if targeting 1.0 and the repo is an HTTP/web service)
+
+- [ ] Security headers set on all responses (HSTS, CSP, X-Frame-Options,
+      X-Content-Type-Options, Referrer-Policy, Permissions-Policy)
+- [ ] Request body size limits enforced on all endpoints
+- [ ] Read/write/idle timeouts configured on the HTTP server (slowloris defense)
+- [ ] Per-handler execution time limits in place
+- [ ] Password-based auth endpoints are rate-limited
+- [ ] CSRF tokens on all state-mutating HTML forms
+- [ ] Passwords hashed with bcrypt, scrypt, or argon2
+- [ ] Session cookies use HttpOnly, Secure, and SameSite attributes
+- [ ] True client IP correctly detected behind reverse proxy (trusted proxy
+      allowlist configured)
+- [ ] CORS restricted to explicit origin allowlist for authenticated endpoints
+- [ ] Error responses do not leak stack traces, SQL queries, or internal paths
+
 # Final
 
 - [ ] `make check` passes

prompts/LLM_PROSE_TELLS.md

@@ -1,9 +1,6 @@
 # LLM Prose Tells
 
-All of these show up in human writing occasionally. No single one is conclusive
+A catalog of patterns found in LLM-generated prose.
-on its own. The difference is concentration. A person might lean on one or two
-of these habits across an entire essay, but LLM output will use fifteen of them
-per paragraph, consistently, throughout the entire piece.
 
 ---
 
@@ -16,20 +13,11 @@ A negation followed by an em-dash and a reframe.
 > "It's not just a tool—it's a paradigm shift." "This isn't about
 > technology—it's about trust."
 
-The single most recognizable LLM construction. Models produce this at roughly 10
-to 50x the rate of human writers. Four of them in one essay and you know what
-you're reading.
-
 ### Em-Dash Overuse Generally
 
-Even outside the "not X but Y" pivot, models use em-dashes at far higher rates
+Even outside the "not X but Y" pivot, models substitute em-dashes for commas,
-than human writers. They substitute em-dashes for commas, semicolons,
+semicolons, parentheses, colons, and periods. The em-dash can replace any other
-parentheses, colons, and periods, often multiple times per paragraph. A human
+punctuation mark, so models default to it.
-writer might use one or two in an entire piece for a specific parenthetical
-effect. Models scatter them everywhere because the em-dash is a flexible
-punctuation mark that can replace almost any other, and models default to
-flexible options. When a piece of prose has more than two or three em-dashes per
-page, that alone is a meaningful signal.
 
 ### The Colon Elaboration
 
@@ -37,34 +25,25 @@ A short declarative clause, then a colon, then a longer explanation.
 
 > "The answer is simple: we need to rethink our approach from the ground up."
 
-Models reach for this in every other paragraph. The construction is perfectly
-normal. The frequency gives it away.
-
 ### The Triple Construction
 
 > "It's fast, it's scalable, and it's open source."
 
-Three parallel items in a list, usually escalating. Always exactly three. Rarely
+Three parallel items in a list, usually escalating. Always exactly three (rarely
-two. Never four. Strict grammatical parallelism that human writers rarely bother
+two, never four) with strict grammatical parallelism.
-maintaining.
 
 ### The Staccato Burst
 
 > "This matters. It always has. And it always will." "The data is clear. The
 > trend is undeniable. The conclusion is obvious."
 
-Runs of very short sentences at the same cadence. Human writers use a short
+Runs of very short sentences at the same cadence and matching length.
-sentence for emphasis occasionally, but stacking three or four of them in a row
-at matching length creates a mechanical regularity that reads as generated.
 
 ### The Two-Clause Compound Sentence
 
-This might be the single most pervasive structural tell, and it's easy to miss
+An independent clause, a comma, a conjunction ("and," "but," "which,"
-because each individual instance looks like normal English. The model produces
+"because"), and a second independent clause of similar length. Every sentence
-sentence after sentence in the same shape: an independent clause, a comma, a
+becomes two balanced halves.
-conjunction ("and," "but," "which," "because"), and a second independent clause
-of similar length. Over and over. Every sentence is two balanced halves joined
-in the middle.
 
 > "The construction itself is perfectly normal, which is why the frequency is
 > what gives it away." "They contain zero information, and the actual point
@@ -74,61 +53,62 @@ in the middle.
 
 Human prose has sentences with one clause, sentences with three, sentences that
 start with a subordinate clause before reaching the main one, sentences that
-embed their complexity in the middle. When every sentence on the page has the
+embed their complexity in the middle.
-same two-part comma-conjunction-comma structure, the rhythm becomes monotonous
-in a way that's hard to pinpoint but easy to feel.
 
 ### Uniform Sentences Per Paragraph
 
-Model-generated paragraphs contain between three and five sentences. This count
+Model-generated paragraphs contain between three and five sentences, a count
-holds steady across an entire piece. If the first paragraph has four sentences,
+that holds steady across a piece. If the first paragraph has four sentences,
-every subsequent paragraph will too. Human writers are much more varied (a
+every subsequent paragraph will too.
-single sentence followed by one that runs eight or nine) because they follow the
-shape of an idea, not a template.
 
 ### The Dramatic Fragment
 
-Sentence fragments used as standalone paragraphs for emphasis, like "Full stop."
+Sentence fragments used as standalone paragraphs for emphasis.
-or "Let that sink in." on their own line. Using one in an entire essay is a
+
-reasonable stylistic choice, but models drop them in once per section or more,
+> "Full stop." "Let that sink in."
-at which point it stops being deliberate and becomes a habit.
 
 ### The Pivot Paragraph
 
 > "But here's where it gets interesting." "Which raises an uncomfortable truth."
 
-One-sentence paragraphs that exist only to transition between ideas. They
+One-sentence paragraphs that exist only to transition between ideas, containing
-contain zero information. The actual point is always in the next paragraph.
+zero information. The actual point is always in the next paragraph.
-Delete every one of these and the piece reads better.
 
 ### The Parenthetical Qualifier
 
 > "This is, of course, a simplification." "There are, to be fair, exceptions."
 
-Parenthetical asides inserted to look thoughtful. The qualifier never changes
+Parenthetical asides inserted to perform nuance without changing the argument.
-the argument that follows it. Its purpose is to perform nuance, not to express a
-real reservation about what's being said.
 
 ### The Unnecessary Contrast
 
-Models append a contrasting clause to statements that don't need one, tacking on
+A contrasting clause appended to a statement that doesn't need one, using
-"whereas," "as opposed to," "unlike," or "except that" to draw a comparison the
+"whereas," "as opposed to," "unlike," or "except that."
-reader could already infer.
 
 > "Models write one register above where a human would, whereas human writers
 > tend to match register to context."
 
-The first clause already makes the point. The contrasting clause restates it
+The contrasting clause restates what the first clause already said. If you
-from the other direction. If you delete the "whereas" clause and the sentence
+delete the "whereas" clause and the sentence still says everything it needs to,
-still says everything it needs to, the contrast was filler.
+the contrast was filler.
+
+### Unnecessary Elaboration
+
+Models keep going after the sentence has already made its point.
+
+> "A person might lean on one or two of these habits across an entire essay, but
+> LLM output will use fifteen of them per paragraph, consistently, throughout
+> the entire piece."
+
+This sentence could end at "paragraph." The words after it repeat what "per
+paragraph" already means. If you can cut the last third of a sentence without
+losing meaning, the last third shouldn't be there.
 
 ### The Question-Then-Answer
 
 > "So what does this mean for the average user? It means everything."
 
-A rhetorical question immediately followed by its own answer. Models lean on
+A rhetorical question immediately followed by its own answer.
-this two or three times per piece because it generates the feeling of forward
-momentum without requiring any actual argument. A human writer might do it once.
 
 ---
 
@@ -136,44 +116,38 @@ momentum without requiring any actual argument. A human writer might do it once.
 
 ### Overused Intensifiers
 
-The following words appear at dramatically elevated rates in model output:
+"Crucial," "vital," "robust," "comprehensive," "fundamental," "arguably,"
-"crucial," "vital," "robust," "comprehensive," "fundamental," "arguably,"
 "straightforward," "noteworthy," "realm," "landscape," "leverage" (as a verb),
-"delve," "tapestry," "multifaceted," "nuanced" (which models apply to their own
+"delve," "tapestry," "multifaceted," "nuanced" (applied to the model's own
-analysis with startling regularity), "pivotal," "unprecedented" (frequently
+analysis), "pivotal," "unprecedented" (applied to things with plenty of
-applied to things with plenty of precedent), "navigate," "foster,"
+precedent), "navigate," "foster," "underscores," "resonates," "embark,"
-"underscores," "resonates," "embark," "streamline," and "spearhead." Three or
+"streamline," "spearhead."
-more on the same page is a strong signal.
 
 ### Elevated Register Drift
 
-Models write one register above where a human would. "Use" becomes "utilize."
+Models write one register above where a human would, replacing "use" with
-"Start" becomes "commence." "Help" becomes "facilitate." "Show" becomes
+"utilize," "start" with "commence," "help" with "facilitate," "show" with
-"demonstrate." "Try" becomes "endeavor." "Change" becomes "transform." "Make"
+"demonstrate," "try" with "endeavor," "change" with "transform," and "make" with
-becomes "craft." The tendency holds regardless of topic or audience.
+"craft."
 
 ### Filler Adverbs
 
 "Importantly," "essentially," "fundamentally," "ultimately," "inherently,"
-"particularly," "increasingly." Dropped in to signal that something matters,
+"particularly," "increasingly." Dropped in to signal that something matters when
-which is unnecessary when the writing itself already makes the importance clear.
+the writing itself should make the importance clear.
 
 ### The "Almost" Hedge
 
-Models rarely commit to an unqualified statement. Instead of saying a pattern
+Instead of saying a pattern "always" or "never" does something, models write
-"always" or "never" does something, they write "almost always," "almost never,"
+"almost always," "almost never," "almost certainly," "almost exclusively." A
-"almost certainly," "almost exclusively." The word "almost" shows up at
+micro-hedge, less obvious than the full hedge stack.
-extraordinary density in model-generated analytical prose. It's a micro-hedge,
-less obvious than the full hedge stack but just as diagnostic when it appears
-ten or fifteen times in a single document.
 
 ### "In an era of..."
 
 > "In an era of rapid technological change..."
 
-A model habit as an essay opener. The model uses it to stall while it figures
+Used to open an essay. The model is stalling while it figures out what the
-out what the actual argument is. Human writers don't begin a piece by zooming
+actual argument is.
-out to the civilizational scale before they've said anything specific.
 
 ---
 
@@ -184,25 +158,20 @@ out to the civilizational scale before they've said anything specific.
 > "While X has its drawbacks, it also offers significant benefits."
 
 Every argument followed by a concession, every criticism softened. A direct
-artifact of RLHF training, which penalizes strong stances. The result is a model
+artifact of RLHF training, which penalizes strong stances.
-that reflexively both-sides everything even when a clear position would serve
-the reader better.
 
 ### The Throat-Clearing Opener
 
 > "In today's rapidly evolving digital landscape, the question of data privacy
 > has never been more important."
 
-The first paragraph of most model-generated essays adds no information. Delete
+The first paragraph adds no information. Delete it and the piece improves.
-it and the piece improves immediately. The actual argument starts in paragraph
-two.
 
 ### The False Conclusion
 
 > "At the end of the day, what matters most is..." "Moving forward, we must..."
 
 The high school "In conclusion,..." dressed up for a professional audience.
-Signals that the model is wrapping up without actually landing on anything.
 
 ### The Sycophantic Frame
 
@@ -223,15 +192,13 @@ the key considerations:"
 > cases it can potentially offer significant benefits."
 
 Five hedges in one sentence ("worth noting," "while," "may not be," "in many
-cases," "can potentially"), communicating nothing. The model would rather be
+cases," "can potentially"), communicating nothing.
-vague than risk being wrong about anything.
 
 ### The Empathy Performance
 
 > "This can be a deeply challenging experience." "Your feelings are valid."
 
-Generic emotional language that could apply equally to a bad day at work or a
+Generic emotional language that could apply to anything.
-natural disaster. That interchangeability is what makes it identifiable.
 
 ---
 
@@ -239,34 +206,28 @@ natural disaster. That interchangeability is what makes it identifiable.
 
 ### Symmetrical Section Length
 
-If the first section of a model-generated essay runs about 150 words, every
+If the first section runs about 150 words, every subsequent section will fall
-subsequent section will fall between 130 and 170. Human writing is much more
+between 130 and 170.
-uneven, with 50 words in one section and 400 in the next.
 
 ### The Five-Paragraph Prison
 
 Model essays follow a rigid introduction-body-conclusion arc even when nobody
-asked for one. Introduction previews the argument. Body presents 3 to 5 points.
+asked for one. The introduction previews the argument, the body presents 3 to 5
-Conclusion restates the thesis in different words.
+points, the conclusion restates the thesis.
 
 ### Connector Addiction
 
-Look at the first word of each paragraph in model output. You'll find an
+The first word of each paragraph forms an unbroken chain of transition words:
-unbroken chain of transition words: "However," "Furthermore," "Moreover,"
+"However," "Furthermore," "Moreover," "Additionally," "That said," "To that
-"Additionally," "That said," "To that end," "With that in mind," "Building on
+end," "With that in mind," "Building on this."
-this." Human prose moves between ideas without announcing every transition.
 
 ### Absence of Mess
 
 Model prose doesn't contradict itself mid-paragraph and then catch the
-contradiction. It doesn't go on a tangent and have to walk it back, use an
+contradiction, go on a tangent and have to walk it back, use an obscure idiom
-obscure idiom without explaining it, make a joke that risks falling flat, leave
+without explaining it, make a joke that risks falling flat, leave a thought
-a thought genuinely unfinished, or keep a sentence the writer liked the sound of
+genuinely unfinished, or keep a sentence the writer liked the sound of even
-even though it doesn't quite work.
+though it doesn't quite work.
-
-Human writing does all of those things. The total absence of rough edges, false
-starts, and odd rhythmic choices is one of the strongest signals that text was
-machine-generated.
 
 ---
 
@@ -276,45 +237,27 @@ machine-generated.
 
 > "This has implications far beyond just the tech industry."
 
-Zooming out to claim broader significance without substantiating it. The model
+Zooming out to claim broader significance without substantiating it.
-has learned that essays are supposed to gesture at big ideas, so it gestures.
-Nothing concrete is behind the gesture.
 
 ### "It's important to note that..."
 
 This phrase and its variants ("it's worth noting," "it bears mentioning," "it
-should be noted") appear at absurd rates in model output. They function as
+should be noted") function as verbal tics before a qualification the model
-verbal tics before a qualification the model believes someone expects.
+believes someone expects.
 
 ### The Metaphor Crutch
 
-Models rely on a small, predictable set of metaphors ("double-edged sword," "tip
+Models rely on a small, predictable set of metaphors: "double-edged sword," "tip
 of the iceberg," "north star," "building blocks," "elephant in the room,"
-"perfect storm," "game-changer") and reach for them with unusual regularity
+"perfect storm," "game-changer."
-across every topic. The pool is noticeably smaller than what human writers draw
-from.
-
----
-
-## How to Actually Spot It
-
-No single pattern on this list proves anything by itself. Humans use em-dashes.
-Humans write "crucial." Humans ask rhetorical questions.
-
-What gives it away is how many of these show up at once. Model output will hit
-10 to 20 of these patterns per page. Human writing might trigger 2 or 3,
-distributed unevenly, mixed with idiosyncratic constructions no model would
-produce. When every paragraph on the page reads like it came from the same
-careful, balanced, slightly formal, structurally predictable process, it was
-probably generated by one.
 
 ---
 
 ## Copyediting Checklist: Removing LLM Tells
 
 Follow this checklist when editing any document to remove machine-generated
-patterns. Go through the entire list for every piece. Do at least two full
+patterns. Do at least two full passes, because fixing one pattern often
-passes, because fixing one pattern often introduces another.
+introduces another.
 
 ### Pass 1: Word-Level Cleanup
 
@@ -328,8 +271,7 @@ passes, because fixing one pattern often introduces another.
 
 2. Search for filler adverbs ("importantly," "essentially," "fundamentally,"
    "ultimately," "inherently," "particularly," "increasingly") and delete every
-   instance where the sentence still makes sense without it. That will be most
+   instance where the sentence still makes sense without it.
-   of them.
 
 3. Look for elevated register drift ("utilize," "commence," "facilitate,"
    "demonstrate," "endeavor," "transform," "craft" and similar) and replace with
@@ -337,7 +279,6 @@ passes, because fixing one pattern often introduces another.
 
 4. Search for "it's important to note," "it's worth noting," "it bears
    mentioning," and "it should be noted" and delete the phrase in every case.
-   The sentence that follows always stands on its own.
 
 5. Search for the stock metaphors ("double-edged sword," "tip of the iceberg,"
    "north star," "building blocks," "elephant in the room," "perfect storm,"
@@ -346,97 +287,114 @@ passes, because fixing one pattern often introduces another.
 
 6. Search for "almost" used as a hedge ("almost always," "almost never," "almost
    certainly," "almost exclusively") and decide in each case whether to commit
-   to the unqualified claim or to drop the sentence entirely. If the claim needs
+   to the unqualified claim or to drop the sentence entirely.
-   "almost" to be true, it might not be worth making.
 
 7. Search for em-dashes and replace each one with the punctuation mark that
    would normally be used in that position (comma, semicolon, colon, period, or
    parentheses). If you can't identify which one it should be, the sentence
-   probably needs to be restructured.
+   needs to be restructured.
+
+8. Remove redundant adjectives. For each adjective, ask whether the sentence
+   changes meaning without it. "A single paragraph" means the same as "a
+   paragraph." "An entire essay" means the same as "an essay." If the adjective
+   doesn't change the meaning, cut it.
+
+9. Remove unnecessary trailing clauses. Read the end of each sentence and ask
+   whether the last clause restates what the sentence already said. If so, end
+   the sentence earlier.
 
 ### Pass 2: Sentence-Level Restructuring
 
-8. Find every em-dash pivot ("not X...but Y," "not just X...Y," "more than
+10. Find every em-dash pivot ("not X—but Y," "not just X—Y," "more than X—Y")
-   X...Y") and rewrite it as two separate clauses or a single sentence that
+    and rewrite it as two separate clauses or a single sentence that makes the
-   makes the point without the negation-then-correction structure.
+    point without the negation-then-correction structure.
 
-9. Find every colon elaboration and check whether it's doing real work. If the
+11. Find every colon elaboration and check whether it's doing real work. If the
-   clause before the colon could be deleted without losing meaning, rewrite the
+    clause before the colon could be deleted without losing meaning, rewrite the
-   sentence to start with the substance that comes after the colon.
+    sentence to start with the substance that comes after the colon.
 
-10. Find every triple construction (three parallel items in a row) and either
+12. Find every triple construction (three parallel items in a row) and either
     reduce it to two, expand it to four or more, or break the parallelism so the
     items don't share the same grammatical structure.
 
-11. Find every staccato burst (three or more short sentences in a row at similar
+13. Find every staccato burst (three or more short sentences in a row at similar
     length) and combine at least two of them into a longer sentence, or vary
     their lengths so they don't land at the same cadence.
 
-12. Find every unnecessary contrast ("whereas," "as opposed to," "unlike," "as
+14. Find every unnecessary contrast ("whereas," "as opposed to," "unlike," "as
     compared to," "except that") and check whether the contrasting clause adds
     information not already obvious from the main clause. If the sentence says
     the same thing twice from two directions, delete the contrast.
 
-13. Check for the two-clause compound sentence pattern. If most sentences in a
+15. Check for the two-clause compound sentence pattern. If most sentences in a
-    passage follow the "\[clause\], \[conjunction\] \[clause\]" structure,
+    passage follow the "\[clause\], \[conjunction\] \[clause\]" structure, first
-    rewrite some of them. Break a few into two sentences. Start some with a
+    try removing the conjunction and second clause entirely, since it's often
-    subordinate clause. Embed a relative clause in the middle of one instead of
+    redundant. If the second clause does carry meaning, break it into its own
-    appending it at the end. The goal is variety in sentence shape, not just
+    sentence, start the sentence with a subordinate clause, or embed a relative
-    sentence length.
+    clause in the middle instead of appending it at the end.
 
-14. Find every rhetorical question that is immediately followed by its own
+16. Find every rhetorical question that is immediately followed by its own
     answer and rewrite the passage as a direct statement.
 
-15. Find every sentence fragment being used as its own paragraph and either
+17. Find every sentence fragment being used as its own paragraph and either
-    delete it or expand it into a complete sentence that adds actual
+    delete it or expand it into a complete sentence that adds information.
-    information.
 
-16. Find every pivot paragraph ("But here's where it gets interesting." and
+18. Check for unnecessary elaboration. Read every clause, phrase, and adjective
-    similar) and delete it. The paragraph after it always contains the actual
+    in each sentence and ask whether the sentence loses meaning without it. If
-    point.
+    you can cut it and the sentence still says the same thing, cut it.
+
+19. Check each pair of adjacent sentences to see if they can be merged into one
+    sentence cleanly. If a sentence just continues the thought of the previous
+    one, combine them using a participle, a relative clause, or by folding the
+    second into the first. Don't merge if the result would create a two-clause
+    compound.
+
+20. Find every pivot paragraph ("But here's where it gets interesting." and
+    similar) and delete it.
 
 ### Pass 3: Paragraph and Section-Level Review
 
-17. Check paragraph lengths across the piece and verify they actually vary. If
+21. Review the last sentence of each paragraph. If it restates the point the
+    paragraph already made, delete it.
+
+22. Check paragraph lengths across the piece and verify they actually vary. If
     most paragraphs have between three and five sentences, rewrite some to be
     one or two sentences and let others run to six or seven.
 
-18. Check section lengths for suspicious uniformity. If every section is roughly
+23. Check section lengths for suspicious uniformity. If every section is roughly
     the same word count, combine some shorter ones or split a longer one
     unevenly.
 
-19. Check the first word of every paragraph for chains of connectors ("However,"
+24. Check the first word of every paragraph for chains of connectors ("However,"
     "Furthermore," "Moreover," "Additionally," "That said"). If more than two
     transition words start consecutive paragraphs, rewrite those openings to
     start with their subject.
 
-20. Check whether every argument is followed by a concession or qualifier. If
+25. Check whether every argument is followed by a concession or qualifier. If
     the piece both-sides every point, pick a side on at least some of them and
     cut the hedging.
 
-21. Read the first paragraph and ask whether deleting it would improve the
+26. Read the first paragraph and ask whether deleting it would improve the
     piece. If it's scene-setting that previews the argument, delete it and start
     with paragraph two.
 
-22. Read the last paragraph and check whether it restates the thesis or uses a
+27. Read the last paragraph and check whether it restates the thesis or uses a
     phrase like "at the end of the day" or "moving forward." If so, either
     delete it or rewrite it to say something the piece hasn't said yet.
 
 ### Pass 4: Overall Texture
 
-23. Read the piece aloud and listen for passages that sound too smooth, too
+28. Read the piece aloud and listen for passages that sound too smooth, too
     even, or too predictable. Human prose has rough patches. If there aren't
     any, the piece still reads as machine output.
 
-24. Check that the piece contains at least a few constructions that feel
+29. Check that the piece contains at least a few constructions that feel
     idiosyncratic: a sentence with unusual word order, a parenthetical that goes
     on a bit long, an aside only loosely connected to the main point, a word
-    choice that's specific and unexpected. If every sentence is clean and
+    choice that's specific and unexpected.
-    correct and unremarkable, it will still read as generated.
 
-25. Verify that you haven't introduced new patterns while fixing the original
+30. Verify that you haven't introduced new patterns while fixing the original
-    ones. This happens constantly. Run the entire checklist again from the top
+    ones. Run the entire checklist again from the top on the revised version.
-    on the revised version.
 
 ---
 
@@ -486,7 +444,6 @@ roughly like this:
 
 The human compared this process to the deleted scene in Terminator 2 where John
 Connor switches the T-800's CPU to learning mode. The model compared it to a
-physician trying to heal itself. Both descriptions are probably accurate.
+physician trying to heal itself. Both are accurate.
 
-This document has been through seven editing passes and it probably still has
+This document has been through ten editing passes and it still has tells in it.
-tells in it.

prompts/REPO_POLICIES.md

@@ -1,6 +1,6 @@
 ---
 title: Repository Policies
-last_modified: 2026-02-22
+last_modified: 2026-03-18
 ---
 
 This document covers repository structure, tooling, and workflow standards. Code
@@ -59,6 +59,73 @@ style conventions are in separate documents:
   `make check`. For server repos, `make check` should run as an early build
   stage before the final image is assembled.
 
+- **Dockerfiles must use a separate lint stage for fail-fast feedback.** Go
+  repos use a multistage build where linting runs in an independent stage based
+  on the `golangci/golangci-lint` image (pinned by hash). This stage runs
+  `make fmt-check` and `make lint` before the full build begins. The build stage
+  then declares an explicit dependency on the lint stage via
+  `COPY --from=lint /src/go.sum /dev/null`, which forces BuildKit to complete
+  linting before proceeding to compilation and tests. This ensures lint failures
+  surface in seconds rather than minutes, without blocking on dependency
+  download or compilation in the build stage.
+
+    The standard pattern for a Go repo Dockerfile is:
+
+    ```dockerfile
+    # Lint stage — fast feedback on formatting and lint issues
+    # golangci/golangci-lint:v2.x.x, YYYY-MM-DD
+    FROM golangci/golangci-lint@sha256:... AS lint
+    WORKDIR /src
+    COPY go.mod go.sum ./
+    RUN go mod download
+    COPY . .
+    RUN make fmt-check
+    RUN make lint
+
+    # Build stage
+    # golang:1.x-alpine, YYYY-MM-DD
+    FROM golang@sha256:... AS builder
+    WORKDIR /src
+
+    # Force BuildKit to run the lint stage before proceeding
+    COPY --from=lint /src/go.sum /dev/null
+
+    COPY go.mod go.sum ./
+    RUN go mod download
+    COPY . .
+    RUN make test
+
+    ARG VERSION=dev
+    RUN CGO_ENABLED=0 go build -trimpath \
+        -ldflags="-s -w -X main.Version=${VERSION}" \
+        -o /app ./cmd/app/
+
+    # Runtime stage
+    FROM alpine@sha256:...
+    COPY --from=builder /app /usr/local/bin/app
+    ENTRYPOINT ["app"]
+    ```
+
+    Key points:
+    - The lint stage uses the `golangci/golangci-lint` image directly (it
+      includes both Go and the linter), so there is no need to install the
+      linter separately.
+    - `COPY --from=lint /src/go.sum /dev/null` is a no-op file copy that creates
+      a stage dependency. BuildKit runs stages in parallel by default; without
+      this line, the build stage would not wait for lint to finish and a lint
+      failure might not fail the overall build.
+    - If the project uses `//go:embed` directives that reference build artifacts
+      (e.g. a web frontend compiled in a separate stage), the lint stage must
+      create placeholder files so the embed directives resolve. Example:
+      `RUN mkdir -p web/dist && touch web/dist/index.html web/dist/style.css`.
+      The lint stage should not depend on the actual build output — it exists to
+      fail fast.
+    - If the project requires CGO or system libraries for linting (e.g.
+      `vips-dev`), install them in the lint stage with `apk add`.
+    - The build stage runs `make test` after compilation setup. Tests run in the
+      build stage, not the lint stage, because they may require compiled
+      artifacts or heavier dependencies.
+
 - Every repo should have a Gitea Actions workflow (`.gitea/workflows/`) that
   runs `docker build .` on push. Since the Dockerfile already runs `make check`,
   a successful build implies all checks pass.
@@ -82,6 +149,42 @@ style conventions are in separate documents:
 - `make test` must complete in under 20 seconds. Add a 30-second timeout in the
   Makefile.
 
+- **`make test` should use the conditional verbose rerun pattern.** Run tests
+  without `-v` (verbose) first. If tests fail, automatically rerun with `-v` to
+  show full output. This keeps CI logs and `docker build` output clean on
+  success (just package/suite summaries) while providing full diagnostic detail
+  on failure (every test case, every assertion). The general shell pattern:
+
+    ```makefile
+    test:
+    	@<test-command> || \
+    		{ echo "--- Rerunning with -v for details ---"; \
+    		  <test-command-with-v>; exit 1; }
+    ```
+
+    Go example:
+
+    ```makefile
+    test:
+    	@go test -timeout 30s -race -cover ./... || \
+    		{ echo "--- Rerunning with -v for details ---"; \
+    		  go test -timeout 30s -race -v ./...; exit 1; }
+    ```
+
+    Python example:
+
+    ```makefile
+    test:
+    	@python -m pytest || \
+    		{ echo "--- Rerunning with -v for details ---"; \
+    		  python -m pytest -v; exit 1; }
+    ```
+
+    The `exit 1` ensures the target always fails after a rerun — the first run
+    already proved the tests are broken, so the build must not pass even if a
+    flaky test happens to succeed on the second attempt. The rerun exists solely
+    for diagnostic output.
+
 - Docker builds must complete in under 5 minutes.
 
 - `make check` must not modify any files in the repo. Tests may use temporary
@@ -98,6 +201,13 @@ style conventions are in separate documents:
   `https://git.eeqj.de/sneak/prompts/raw/branch/main/.gitignore` when setting up
   a new repo.
 
+- **No build artifacts in version control.** Code-derived data (compiled
+  bundles, minified output, generated assets) must never be committed to the
+  repository if it can be avoided. The build process (e.g. Dockerfile, Makefile)
+  should generate these at build time. Notable exception: Go protobuf generated
+  files (`.pb.go`) ARE committed because repos need to work with `go get`, which
+  downloads code but does not execute code generation.
+
 - Never use `git add -A` or `git add .`. Always stage files explicitly by name.
 
 - Never force-push to `main`.
@@ -121,6 +231,66 @@ style conventions are in separate documents:
 - Dockerized web services listen on port 8080 by default, overridable with
   `PORT`.
 
+- **HTTP/web services must be hardened for production internet exposure before
+  tagging 1.0.** This means full compliance with security best practices
+  including, without limitation, all of the following:
+    - **Security headers** on every response:
+        - `Strict-Transport-Security` (HSTS) with `max-age` of at least one year
+          and `includeSubDomains`.
+        - `Content-Security-Policy` (CSP) with a restrictive default policy
+          (`default-src 'self'` as a baseline, tightened per-resource as
+          needed). Never use `unsafe-inline` or `unsafe-eval` unless
+          unavoidable, and document the reason.
+        - `X-Frame-Options: DENY` (or `SAMEORIGIN` if framing is required).
+          Prefer the `frame-ancestors` CSP directive as the primary control.
+        - `X-Content-Type-Options: nosniff`.
+        - `Referrer-Policy: strict-origin-when-cross-origin` (or stricter).
+        - `Permissions-Policy` restricting access to browser features the
+          application does not use (camera, microphone, geolocation, etc.).
+    - **Request and response limits:**
+        - Maximum request body size enforced on all endpoints (e.g. Go
+          `http.MaxBytesReader`). Choose a sane default per-route; never accept
+          unbounded input.
+        - Maximum response body size where applicable (e.g. paginated APIs).
+        - `ReadTimeout` and `ReadHeaderTimeout` on the `http.Server` to defend
+          against slowloris attacks.
+        - `WriteTimeout` on the `http.Server`.
+        - `IdleTimeout` on the `http.Server`.
+        - Per-handler execution time limits via `context.WithTimeout` or
+          chi/stdlib `middleware.Timeout`.
+    - **Authentication and session security:**
+        - Rate limiting on password-based authentication endpoints. API keys are
+          high-entropy and not susceptible to brute force, so they are exempt.
+        - CSRF tokens on all state-mutating HTML forms. API endpoints
+          authenticated via `Authorization` header (Bearer token, API key) are
+          exempt because the browser does not attach these automatically.
+        - Passwords stored using bcrypt, scrypt, or argon2 — never plain-text,
+          MD5, or SHA.
+        - Session cookies set with `HttpOnly`, `Secure`, and `SameSite=Lax` (or
+          `Strict`) attributes.
+    - **Reverse proxy awareness:**
+        - True client IP detection when behind a reverse proxy
+          (`X-Forwarded-For`, `X-Real-IP`). The application must accept
+          forwarded headers only from a configured set of trusted proxy
+          addresses — never trust `X-Forwarded-For` unconditionally.
+    - **CORS:**
+        - Authenticated endpoints must restrict `Access-Control-Allow-Origin` to
+          an explicit allowlist of known origins. Wildcard (`*`) is acceptable
+          only for public, unauthenticated read-only APIs.
+    - **Error handling:**
+        - Internal errors must never leak stack traces, SQL queries, file paths,
+          or other implementation details to the client. Return generic error
+          messages in production; detailed errors only when `DEBUG` is enabled.
+    - **TLS:**
+        - Services never terminate TLS directly. They are always deployed behind
+          a TLS-terminating reverse proxy. The service itself listens on plain
+          HTTP. However, HSTS headers and `Secure` cookie flags must still be
+          set by the application so that the browser enforces HTTPS end-to-end.
+
+    This list is non-exhaustive. Apply defense-in-depth: if a standard security
+    hardening measure exists for HTTP services and is not listed here, it is
+    still expected. When in doubt, harden.
+
 - `README.md` is the primary documentation. Required sections:
     - **Description**: First line must include the project name, purpose,
       category (web server, SPA, CLI tool, etc.), license, and author. Example: