DEV Community: ZEUS LAB

A 60% win rate can still halve the account: risk of ruin and the Kelly fraction over 5,000 seeded paths

ZEUS LAB — Sat, 14 Nov 2026 01:09:47 +0000

A 60% win rate, and the account can still lose half of itself on the way.

That is not a rare streak of bad luck. With a 60% win rate, an average win of 0.8 times the average loss, and 10% of the balance at stake on every trade, 36.860% of 5,000 simulated paths touched half of the starting balance at least once within 200 trades. The 10% is not arbitrary: it is the Kelly fraction for those inputs.

Every number below is a calculation from our free in-browser calculator, with the same formulas and the same random seed. It is not a forecast and not trading advice. The model is deliberately simple: every trade is independent, wins b units per unit risked with probability p and loses 1 unit with probability 1 − p, with p and b fixed. So a win multiplies the balance by (1 + b × stake) and a loss by (1 − stake). No fees, no slippage, no correlation between trades.

1. The win rate does not decide where the balance goes

At least three numbers do:

p, the win rate;
b, the payoff ratio: average win ÷ average loss;
r, the stake: what one trade can lose, as a share of the balance at that moment.

At p = 0.6 and b = 0.8 the edge per trade is small: 0.6 × 0.8 − 0.4 × 1 = 0.08 units per unit risked. The same edge can take very different roads depending on r, because the balance compounds. After a 50% fall, getting back to the start takes a 100% gain.

2. The Kelly fraction: the growth-maximising stake

The Kelly criterion gives the stake that maximises the expected logarithmic growth of the balance:

f* = p − (1 − p) / b

For p = 0.6 and b = 0.8, f* = 0.6 − 0.4 / 0.8 = 0.10, so 10% of the balance. For p = 0.5 and b = 1.5 it is 16.667%. The formula assumes b > 0 and a stake between 0 and 1; a negative result only means the inputs carry no edge in this model, and it is not a signal of any kind.

The same formula also marks where more stake starts to hurt. Expected log growth per trade, g(f) = p·ln(1 + b·f) + (1 − p)·ln(1 − f), at p = 0.6 and b = 0.8:

Stake	g(f) per trade
2%	+0.00144
5%	+0.00302
10% (Kelly)	+0.00403
15%	+0.00299
20%	−0.00021

For these inputs, growth peaks at 10% and falls on both sides; at a 20% stake the expected log growth is negative in this model. Half-Kelly (5%) keeps about 75% of the peak growth, again for these inputs.

One more assumption sits inside the formula: it treats p and b as known. In practice they are estimates from a limited trade log. If the estimate leans optimistic, the "optimal" stake is already too large.

3. Risk of ruin: look at the spread of paths, not the average

Kelly maximises long-run growth. An account does not live the average, though; it lives one path. So we ran 5,000 seeded paths with the same inputs and counted the share whose balance fell to 50% of the starting balance at least once within 200 trades. The table also shows the median maximum drawdown, the largest peak-to-trough decline on each path (in brackets: the 95% Wilson interval for the share, inside this model):

Stake	Touched −50%	95% interval	Median max drawdown
2%	0.020%	0.004% – 0.113%	17.582%
5%	7.300%	6.611% – 8.054%	39.769%
10% (Kelly)	36.860%	35.533% – 38.207%	67.596%

At exactly the Kelly stake, more than one path in three fell to half of the starting balance along the way, and the 95th percentile of the maximum drawdown was 89.595%. Among the three stakes tested, the growth-maximising 10% also had the largest median maximum drawdown.

4. Losing streaks under independent outcomes

Losses come in runs even at 60%. The probability of at least one run of 8 losses within 200 trades is 7.356% (exact, by dynamic programming). At a 50% win rate it is 31.970%.

The table compares fixed stakes only; a stake that changes after losses was not simulated. In this model, a larger fixed stake sits further down the table, where the spread of paths is wider.

5. Reproduce it

This is the core of the calculator in Python, with the same seeded generator. It prints the Kelly fraction and the three ruin shares above, to the last digit:

import math

def mulberry32(seed):  # the same small seeded generator the browser calculator uses
    s = seed & 0xFFFFFFFF
    def rnd():
        nonlocal s
        s = (s + 0x6D2B79F5) & 0xFFFFFFFF
        v = ((s ^ (s >> 15)) * (1 | s)) & 0xFFFFFFFF
        v ^= (v + (((v ^ (v >> 7)) * (61 | v)) & 0xFFFFFFFF)) & 0xFFFFFFFF
        return ((v ^ (v >> 14)) & 0xFFFFFFFF) / 4294967296
    return rnd

def ruin_share(p, b, r, trades=200, floor=0.50, paths=5000, seed=20261114):
    """Share of paths whose balance touches (1 - floor) of the start at least once."""
    rnd, win, loss = mulberry32(seed), math.log1p(r * b), math.log1p(-r)
    limit, hits = math.log1p(-floor), 0
    for _ in range(paths):
        eq, ruined = 0.0, False
        for _ in range(trades):
            eq += win if rnd() < p else loss
            ruined = ruined or eq <= limit + 1e-12
        hits += ruined
    return hits / paths

p, b = 0.60, 0.8
print(f"Kelly fraction: {p - (1 - p) / b:.3%}")
for r in (0.02, 0.05, 0.10):
    print(f"risk {r:.0%}: {ruin_share(p, b, r):.3%} of 5,000 paths touched -50%")

Our output:

Kelly fraction: 10.000%
risk 2%: 0.020% of 5,000 paths touched -50%
risk 5%: 7.300% of 5,000 paths touched -50%
risk 10%: 36.860% of 5,000 paths touched -50%

Working in log space turns compounding into addition and makes the threshold test a single comparison; it is still floating-point arithmetic, hence the small tolerance.

6. A limit you decided is easier to keep when a machine keeps it

A limit set by calculation is only as good as whatever enforces it. One design hands that job to a small local process:

the numbers come first: daily loss limit, per-strategy limit, what to do when the data feed goes stale;
when a configured limit is detected as touched, it tries to stop the process you named, without asking you in the moment;
every stop is written to a log chained with SHA-256, so an edit to one entry breaks the chain on the next check (rewriting the whole chain is only caught against a copy kept elsewhere);
configuration files are read, not used, to check the permission settings declared there and to flag secrets written into them.

A tool built this way places no trades and predicts nothing. Stopping a process does not close open positions or cancel resting orders, and it is not a guaranteed loss ceiling.

Try it with your own numbers

The calculator runs in the browser: win rate, payoff, stake, number of trades, the drawdown you treat as ruin and the streak length. Your inputs are not sent anywhere. The same page shows the local audit-and-stop kit, its file list and its tests:

https://zero-trace-ship-kit.zeus-lab-global.workers.dev/quant/?utm_source=devto

Calculation only. These are formula values and seeded simulation values, not a forecast, and not a recommendation of any trade, broker or product.

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

Architecting a Solo Multi-AI Studio: Separation of Powers and Deterministic Pre-Release Gates

ZEUS LAB — Fri, 13 Nov 2026 22:08:03 +0000

One chat window, one model, every job: the idea, the structure, the code and the final check. Sooner or later, though, the same model can quietly approve its own mistake, and a leaked key, an unmeasured number or a broken link goes out with your name on it.

What changed things for us was not a better prompt. It was a separation of powers. The model that builds never grades its own work. A second reader sees only the finished text and the rules. And the checks that must never be argued with are done by plain code at commit time. In our own test, that commit-time leak gate stops 32 of 32 planted samples and raises 0 false alarms on 17 clean look-alikes. That is a figure for planted samples, not a detection rate for real folders.

Here is the setup, piece by piece, so you can rebuild it with the models you already use.

Why one window degrades

Three things go wrong when one conversation does everything.

Context mixing. The brainstorm, the pricing math and the deployment details share one window. Every new answer is shaped by everything before it, including the parts that were wrong.
Self-grading. A model asked to review what it just wrote tends to agree with itself. It has read its own reasoning, so it walks the same path to the same blind spot.
Nobody says no. There is no role whose job is to refuse. Speed wins every argument.

None of this is a model problem. It is an organisational one, and the old fix applies: split the powers.

Four roles, one decision-maker

Role	Owns	Does not
Vision	the story, the market, the plan	write the final code
Structure	math, prices, edge cases, a second opinion	approve its own numbers
Execution	code, files, film, the scheduled runs	grade its own output
Blind audit	reading the artifact against the rules	see the maker's reasoning

Above them sits one person who decides: execute, abort, or mutate with a stated reason. As one example of an assignment, in our setup a long-context model takes vision, a second vendor's model takes structure and, in a separate session, the blind review, and a coding agent executes. The assignment matters less than the rule that no role holds two powers.

Handoffs that keep the powers apart

Separation only works if the handoffs are clean.

Write a brief, not a chat. Inputs, constraints, a definition of done, and what must not be touched. A brief can be read cold by a model that saw nothing else.
Seal your own answer first. Before asking for review, the maker writes its proposal and seals it. Then the reviewers are asked in parallel, and neither sees the other's answer. Disagreement is the signal you are paying for.
Review in an empty room. Run the reviewer in an empty temporary folder and hand it only the text to read and the rules to check against. No repository, no history, no maker's notes. A reader that never sees the reasoning is less likely to inherit its blind spot.

Deterministic gates: what AI must not judge

Some questions are not up for debate: did a secret leak, does a number have a source, does every link answer. These run as plain code, at commit time and again before release.

Leaks: personal names, machine paths that reveal a login name, secret keys, private contacts.
Claims: figures with no measurement behind them, and wording that overstates what was measured.
Links: every public link must answer; a retired page counts as alive only while a real redirect exists.
House rules: the palette, public times in UTC, loudness and frame rate for any film.

The wiring is ordinary. A sketch, with placeholder file names:

#!/bin/sh
# .git/hooks/pre-commit: a non-zero exit stops the commit
python3 tools/check_leaks.py --staged || exit 1
python3 tools/check_claims.py --staged || exit 1

The agent gets a seat belt too. Claude Code can run a hook before every tool call; exit code 2 refuses the call, and the message on standard error goes back to the agent. This one, from our MIT starter, refuses a commit that tries to skip the checks:

SKIP_FLAG = "--no-" + "verify"
RULE = re.compile(r"git\s+(commit|push)\b[^\n;|&]*" + re.escape(SKIP_FLAG))

def main() -> int:
    try:
        data = json.loads(sys.stdin.read() or "{}")
        if data.get("tool_name") == "Bash":
            command = str((data.get("tool_input") or {}).get("command", ""))
            if RULE.search(command):
                sys.stderr.write("guard: refused. Fix the cause instead.\n")
                return 2
    except Exception:
        return 0
    return 0

{"hooks": {"PreToolUse": [{"matcher": "Bash",
  "hooks": [{"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/hooks/guard_min.py\""}]}]}}

It is a text match on the command, nothing more. Treat it as a seat belt, not a sandbox. Exceptions raised inside the hook are caught and let the call through, so a bug in its logic does not block your work.

Keeping the budget fixed

Metered API keys are the quiet way a solo studio overspends. The same hook pattern can refuse a tool call that touches a metered-key variable, so the agents work through the flat-rate tools you are already signed into. The cost follows the plan you chose rather than a per-call meter.

A rhythm that runs without you

The studio wakes on a schedule (four times a day for us), catches up once after the machine has slept, and picks up any new directive the founder leaves in a shared folder. What reaches the human is one card: what changed, what was measured, and one decision, with execute, abort or mutate.

What this does not do

It does not replace judgment. It moves judgment to the one place it belongs.
The gates catch only what they are written to catch. "No findings" is not proof that nothing is there.
A blind reviewer can be wrong. Two reviewers who disagree are still cheaper than one who agrees with everything.

Try it

The pre-release leak check runs in your browser, and the files you scan are not uploaded: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/?utm_source=devto
The MIT starter with the hook above: https://github.com/ZEUSLABZERO/zeus-harness-starter
The full blueprint (role directives, gates, a budget ledger and a self-check), if you want it ready-made: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/studio/?utm_source=devto

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

Before you publish an MCP server: seven checks for stdio and for secrets

ZEUS LAB — Thu, 12 Nov 2026 23:27:23 +0000

An MCP server that connects and then drops at once. Or one that works, gets published, and carries a real key in its example configuration. Both are the kind of flaw you can find in the few minutes before release. Here are seven checks for a local MCP server on the stdio transport.

The reference MCP servers repository shows v2.4.0 dated 2026-11-11, and MCP servers are prominent among this week's new public repositories (we read the headlines and dates only and verified nothing behind them). More people are writing and publishing their own, so this is where to look first.

The full checklist in English and Japanese, with questions and answers: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/guides/mcp-server-stdio-secrets-checklist/?utm_source=devto

1. Standard output carries protocol messages only

The specification (Transports, version 2025-06-18; read on its page on 2026-11-12 UTC) says for stdio:

The server must not write anything to its standard output that is not a valid MCP message.
Messages are delimited by newlines and must not contain embedded newlines.
The server may write logs to standard error.

A debugging print, a library banner, a progress line: any one of them on standard output is read by the client as a message, and the session breaks. Send every log line to standard error.

2. Try the handshake by hand

The first thing on standard output should be one JSON-RPC response to the initialize request: the same id, and a result. Anything before it is a bug.

printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"check","version":"0"}}}' \
  | python3 your_server.py 2>/dev/null | head -c 400

This is a quick look, not a conformance test. The protocol version is one published version; use the one your server supports.

3. No secrets in committed configuration

Keep keys out of .mcp.json and out of example configurations. Read them inside the server from its environment, and commit a placeholder.

{ "mcpServers": { "example": { "command": "python3", "args": ["server.py"], "env": { "API_TOKEN": "${API_TOKEN}" } } } }

Whether a ${VAR} placeholder is expanded depends on the client, so check yours. In our count of 100 public AI and MCP repositories on 2026-11-12, 7 had a .mcp.json at the root (existence only; we did not read the contents).

4. Ignore what stays local

In .gitignore and, if you ship an image, in .dockerignore as well. .gitignore does not keep a file out of docker build.

.env
.env.*
.claude/settings.local.json
*.pem

5. Tool descriptions say what the tool does, nothing else

A description is read by the model as text. Do not put instructions to the model, credentials or internal addresses in it.

6. Default to reading, make writing explicit

A server that only reports is easier to trust and to review. If a tool changes something, say so in its name and description.

7. Scan the folder you are about to publish

Last, look at the folder itself. A free MIT-licensed command lists supported leak patterns in a folder's text files, with the values masked.

python3 zero_trace_lite.py .

In our independent test it detected 32 of 32 planted samples (a figure for planted samples, not a detection rate for real folders). None found is not proof that nothing is there. The command reports only; it does not stop a commit.

To try it in a browser, there is a scanner you drop a folder onto (the check runs in the browser and the files under inspection are not sent): https://zero-trace-ship-kit.zeus-lab-global.workers.dev/?utm_source=devto

In short

If it connects and drops, suspect standard output first.
Keys come from the environment; the repository carries a placeholder.
Scan the folder once, right before release.

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

We counted ignore rules in 100 public AI and MCP repositories (no names, script included)

ZEUS LAB — Thu, 12 Nov 2026 14:20:10 +0000

A missing line in .gitignore is not a leak. But it is the first thing between a secret and a public history, so we wanted to know how often the basic lines are actually there.

On 2026-11-12 we took 100 active public AI and MCP repositories and counted. We did not judge, and we name no repository here or in any file we publish. Nothing was reported to anyone.

The page with every count, the method and the script: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/report/?utm_source=devto

What we counted

	Count
Have a `.gitignore` at the root	97 / 100
Have an `.env` pattern in it	76 / 100
Have a `.claude` / `settings.local.json` pattern in it	59 / 100
Have a key-file or secrets pattern in it	26 / 100
Have a `Dockerfile` at the root	30 / 100
...of those, have a `.dockerignore`	28 / 30
...of those, keep `.env` out of the build context	18 / 30
...of those, keep `.git` out of the build context	21 / 30
Keep Claude Code settings in the repository (`.claude/`)	12 / 100
...of those, ignore the local settings file	11 / 12
Have a file named `.env` on the default branch (existence only)	1 / 100
Have `.claude/settings.local.json` on the default branch (existence only)	2 / 100

The one that stood out to us

The Docker rows. A .dockerignore is nearly always present when there is a Dockerfile (28 of 30), yet 12 of those 30 have no .env pattern in it. .gitignore keeps a file out of Git; it does not keep it out of docker build .. If an image built on a developer machine is pushed, a local .env can travel inside a layer. Whether it does depends on the COPY lines, which we did not read.

How to read these numbers

An absent rule is not a leak. The file may not exist, a global ignore may cover it, or habit may.
"Pattern present" is a line-by-line match of common spellings, not a full implementation of gitignore semantics.
For the two "existence only" rows we asked whether the path exists on the default branch. We never downloaded the contents, so a file named .env may be a harmless placeholder.
The sample moves daily. A later run gives somewhat different counts.

The sample and the method

Public, non-archived, non-fork repositories with at least 50 stars, pushed to within 30 days, from GitHub's public search for four topics (mcp, ai-agents, claude-code, llm), merged in turn until 100. For each repository two public files are read (.gitignore, .dockerignore) and five paths are checked for existence. No key, no account: Python standard library plus curl. The script is on the report page; run it and you get today's counts.

Check your own folder

Three lines cover most of it:

# .gitignore
.env
.env.*
.claude/settings.local.json

and the same .env lines in .dockerignore. To see what a folder would give away before you publish it, the free scanner runs in the browser (the files are not uploaded) and the command-line edition is MIT: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/?utm_source=devto

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

Wiring gates, a second-AI review and a live board into Claude Code work (the hooks, and three things an audit made us fix)

ZEUS LAB — Thu, 12 Nov 2026 11:30:38 +0000

It is late, and the agents are still working. You wait for a reply, carry it to another AI, then check what comes back. Between those handoffs, the hours you meant to spend creating quietly unravel.

This post shows the wiring we use to take those handoffs out of our hands: four small pieces around Claude Code, each a short standard-library Python script. It also shows what went wrong when we pointed the same wiring at our own product page.

The board, running with sample data, and the diagram: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/harness/?utm_source=devto

Every box is something that exists in the repository or at a public address; the lines show stage-to-stage flow. Zoomable version on the page above.

The four pieces

Piece	Claude Code mechanism	What it does
Tool guard	`PreToolUse` hook	Refuses a call before it runs when its text matches a rule
Stop report	`Stop` hook	Runs the commit checks when the agent stops and says which one does not pass yet
Review relay	a script, no hook	Hands a text to a second AI's CLI and saves the answer as a file
Event board	`PostToolUse` / `SubagentStop` hooks	Writes one line per event; a local page shows them

The hook entries in .claude/settings.json:

{
  "hooks": {
    "PreToolUse":  [{"matcher": "Bash|Edit|Write", "hooks": [{"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/hooks/guard.py\""}]}],
    "PostToolUse": [{"matcher": "Edit|Write|Bash", "hooks": [{"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/hooks/log_event.py\""}]}],
    "Stop":        [{"hooks": [{"type": "command", "command": "python3 \"$CLAUDE_PROJECT_DIR/hooks/commit_gate.py\" --report"}]}]
  }
}

The guard is a text match, and that is all it is

A PreToolUse hook receives the tool name and its input as JSON on stdin. Exit code 2 refuses the call and the message on stderr goes back to the agent. Ours checks two things: a metered API key variable being given a value or read, and a commit command that carries the flag for skipping checks.

It does not follow what a script does once it runs. Other ways around a check are not matched. It is a seat belt for the agent's own commands, not a sandbox. We say this plainly because the first version of our page did not (see below).

It also stops its author. While writing this article, the guard refused our own shell command, because the command contained an example of the very phrase it looks for. We narrowed that rule to shell commands, so prose in a file no longer trips it, and wrote the fix with the phrase split in two. Loosening the rule to get through was not an option we allow ourselves.

Only names are logged

The event hook writes the kind of event, a name (tool, check or agent), a state and a duration. Tool inputs and outputs are never written. A test plants a value in a command and asserts that the log does not contain it.

Relay: a second AI reads it, a guard runs first

relay/cross_ai_audit.sh runs the commit checks, then passes the text to each configured CLI in turn (for us: a Gemini CLI, then a Codex CLI, both under flat-rate sign-ins — no metered API key is set or read), then writes a packet for a detached auditor role. Before anything is sent, a guard command runs on the text; if it fails, nothing is sent. What the second AI's service does with the text is governed by that service's terms, under your account.

What the reviews found in our own listing

We ran the relay on the store text of this kit before publishing. Both reviewers returned FIX. Then a detached auditor role unpacked the packages and ran their tests. The findings we acted on:

A stale license inside the bundle. It still said "two kits" after a third was added. The checksums were right and the tests passed; only a reader could catch it. Fixed, version raised.
"Per year" next to "one-time". An allowance that covers 12 months from purchase read like a yearly renewal. Reworded to "within 12 months of purchase, 25 in total".
"Enforced hooks". The auditor tried four ways around the guard and they passed. The word came out, and the page now says exactly what is matched.

None of these were caught by a mechanical check. All three were about words.

Measured, on our machine

10 tests in the kit: install, merge and removal of settings; no input in the log; the guard; the stop report; a real blocked commit; the relay with its guard; the cross-AI audit; the board server.
36 files including the checksum list. Python standard library only.
Tested on macOS with Python 3.14 and git 2.x. Windows has not been tested.

Limits

A passing check is not a guarantee. The board shows the events it receives; it does not watch any AI service by itself. Nothing here promises results. AI subscriptions are separate from the kit and are yours.

The whole set — hooks, roles, skills, relay, board, diagram generator and installer — is the ZEUS LAB Autonomous Harness & Telemetry Kit, $149 one-time: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/harness/?utm_source=devto

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

Counting which comes first, the loss limit or the profit target: an in-browser Monte Carlo, cross-checked by a Python twin

ZEUS LAB — Thu, 12 Nov 2026 07:27:44 +0000

Late at night, you open the trade history again. After all those days of work, one large loss holds your attention. Before closing the screen, you want to look once more at the limits you chose.

The calculator runs in your browser, free, with zero network requests: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/quant/?utm_source=devto

Take an account with rules such as "lose no more than 5% in a day, no more than 10% in total, done when profit reaches 8%". With the same win rate and payoff ratio, changing only the risk per trade reorders which rule you hit first. This post implements a small Monte Carlo that counts it in plain JavaScript, then writes the same model again in Python and uses agreement between the two as the check.

Everything here is arithmetic on numbers you enter. It is not a recommendation to trade, not a forecast and not investment advice, and it names no firm or product.

The model

A trade is +payoff × risk with probability p, otherwise −risk. Trades are independent.
Risk is a constant share of the start balance. The balance starts at 100.
n trades a day for D days.
Rules are checked after every trade:
- maximum loss: balance at or below 100 × (1 − M) (from the peak when trailing)
- daily loss limit: fall from the day's opening balance of at least opening × d
- profit target: balance at or above 100 + T
The first one to happen stops the path. The balance stays at its value from then on, and the maximum drawdown is measured up to that moment. The balance cannot go below 0.
A trade that reaches the daily limit and the maximum loss together is counted separately as "both".

Real trading has variable outcomes, streaks, fees and slippage. The model has none of them.

Implementation (JavaScript, no dependencies)

The generator is the seedable mulberry32. Math.random() cannot be seeded, so a result could not be reproduced.

function mulberry32(a){return function(){a|=0;a=a+0x6D2B79F5|0;
  let t=Math.imul(a^a>>>15,1|a);t=t+Math.imul(t^t>>>7,61|t)^t;
  return((t^t>>>14)>>>0)/4294967296}}

function simulate(p){
  const rnd=mulberry32(p.seed),win=p.win/100,gain=p.risk*p.rr,loss=p.risk;
  let pass=0,bDaily=0,bMax=0,bBoth=0;
  for(let r=0;r<p.runs;r++){
    let bal=100,peak=100,outcome=0;
    for(let d=0;d<p.days&&outcome===0;d++){
      const dayStart=bal;
      for(let t=0;t<p.tpd&&outcome===0;t++){
        bal+=rnd()<win?gain:-loss;if(bal<0)bal=0;
        if(bal>peak)peak=bal;
        const hitMax=bal<=(p.trail?peak:100)*(1-p.maxl/100);
        const hitDaily=dayStart-bal>=dayStart*p.daily/100;
        if(hitMax&&hitDaily)outcome=4;      // same trade reaches both
        else if(hitMax)outcome=3;
        else if(hitDaily)outcome=2;
        else if(bal>=100+p.target)outcome=1;
      }
    }                                        // the path stops at the first event
    if(outcome===1)pass++;else if(outcome===2)bDaily++;else if(outcome===3)bMax++;else if(outcome===4)bBoth++;
  }
  return{pass:pass/p.runs*100,daily:bDaily/p.runs*100,max:bMax/p.runs*100,both:bBoth/p.runs*100};
}

Results (calculated values)

Win rate 45%, payoff 1.5, 3 trades a day, 30 days, daily limit 5%, maximum loss 10% from the start balance, target 8%, 5,000 paths, seed 1. Only the risk per trade changes.

Risk per trade	Target first	Daily limit first	Maximum loss first	Both at once	None	Median max drawdown
0.5%	46.8%	0.0%	1.3%	0.0%	51.9%	3.9%
1%	76.9%	0.0%	12.8%	0.0%	10.3%	5.3%
2%	52.1%	46.9%	0.2%	0.8%	0.0%	5.8%
3%	46.3%	52.9%	0.1%	0.7%	0.0%	5.9%

The maximum drawdown is measured up to the moment the path stops. A "0.0%" in the table means it did not occur in 5,000 paths, not that it cannot happen.

At 0.5% the rules are almost never touched, but half the paths do not reach the target in 30 days either.
At 2%, "daily limit first" jumps from 0.0% to 46.9%. The reason is plain: three losses in a day are 3 × 2% = 6%, past the 5% limit. At 1%, three losses are 3%, so in this model the daily limit cannot be reached at all.
So under these inputs the shape of the result is set by whether trades per day × risk per trade crosses the daily limit.

Across seeds 1, 2 and 3 the "target first" share at 1% risk was 76.9%, 76.4% and 75.5%. With 5,000 paths the sampling error of a share q is √(q(1−q)/5000), about ±0.6 points at 77% (one standard error, from the formula). That covers the random draw only, not errors in the assumptions.

With a trailing maximum loss, "maximum loss first" at 1% risk goes from 12.8% to 20.4%.

The check: write the model twice

A simulation produces plausible numbers even when it is wrong. So the same model is written independently in Python and compared with the JavaScript result. mulberry32 is 32-bit integer arithmetic; in Python that is done with masks.

M = 0xFFFFFFFF
def mulberry32(seed):
    a = seed & M
    def rnd():
        nonlocal a
        a = (a + 0x6D2B79F5) & M
        t = ((a ^ (a >> 15)) * (1 | a)) & M
        t = ((t + (((t ^ (t >> 7)) * (61 | t)) & M)) & M) ^ t
        return ((t ^ (t >> 14)) & M) / 4294967296
    return rnd

With the same random sequence and the same order of floating-point operations, the two must agree to the last bit. The page writes its results as JSON when opened with ?selftest=1; headless Chrome opens it and a script compares.

quant model: AGREE — 5 cases · largest difference 0.00e+00

Five cases of 5,000 paths each, largest difference zero (Python 3.14, Chrome, an Apple Silicon Mac, one run). A difference stops the release. This catches slips such as swapping the order of the rule checks on one side.

There is also a boundary test. With a 20% win rate, a payoff of 0.3, 5% risk and 120 days, nearly every path is disqualified within days. An implementation that keeps computing after disqualification piles up fixed-size losses and reports a maximum drawdown far above 100% (our first version had this mistake). With the stop in place, the largest maximum drawdown in the sample under these inputs is 13.95%, inside "maximum loss 10% + one 5% risk". The check stops the release if that bound is exceeded. It does not catch a misunderstanding shared by both implementations.

Use and limits

Calculator: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/quant/?utm_source=devto — move a slider and it recomputes. Nothing you enter is sent anywhere; the page's CSP forbids network requests.
Account rules differ between providers and change. Enter the numbers from the current official rules.
Win rate and payoff are assumed numbers.
This counts how often the loss limits are reached under the conditions and rules you enter. It does not forecast sudden market moves and does not reproduce any firm's actual rule evaluation.
A tool that does the same counting on your own trade-history CSV, resampling whole days, is in the paid kit described on the same page.

Advertisement (affiliate link): if you sign up through this link, ZEUS LAB may receive compensation. It leads to TradingView's Black Friday information page; check the link for availability, eligible plans, prices and conditions. You do not need any subscription to use this calculator. TradingView

Once more: this is arithmetic and says nothing about what or how to trade. Trading can lose all of the money you commit.

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.

Claude Code's "Don't ask again" can retain secrets. Check your files before pushing.

ZEUS LAB — Wed, 11 Nov 2026 22:24:52 +0000

Your hand pauses over Publish. Hours of careful work are ready to leave your machine—but did something private find its way in? The screen goes dark, and the question follows you.

Clicked "Don't ask again" in Claude Code? Check the settings file before publishing.

Research published in November 2026 showed that approved commands can leave embedded secrets in .claude/settings.local.json.

The file is normally excluded from Git, but adding an already tracked file to .gitignore does not untrack it.

Start by scanning the folder you plan to publish, including its AI configuration files.

The free Zero-Trace Ship Kit scanner processes selected files inside your browser. The files you scan are not uploaded to a server.

Scan your files for free

With the full kit's Git hooks installed and enabled, supported findings stop the commit or push.

$39 for an individual, or $149 for Team use by up to 10 people in one organization. One-time purchase.

"No findings" means no supported pattern was detected; it does not prove that the files contain no secrets.

Demo (25 seconds): found → commit stopped → fixed → passed. The full kit run in a real git repository with made-up data planted in it, exit codes included. https://zero-trace-ship-kit.zeus-lab-global.workers.dev/?utm_source=devto#demo

What you get	Free	Full kit
Browser scanner	yes	yes
Text-file report command	yes	yes
Blocks commit and push automatically	—	yes
Checks ZIPs inside ZIPs, photo GPS, PDF and Office authors	—	yes
Cleaned distribution ZIP with a SHA-256 manifest	—	yes

Carry this check into your next commit. Automate pre-commit and pre-push scanning with the full kit.
Enabled hooks block supported findings. Cleaned distribution ZIP generation is included.
Individual $39 / Team $149 for up to 10 people in one organization. One-time purchase. No subscription.

Buy Individual — $39 / Team — $149, up to 10 people

1. What is happening

When you approve a command in Claude Code with "don't ask again", the approved command is saved as a literal string under permissions.allow in the project's .claude/settings.local.json. If the command carried a password or token inline, that is saved too.

{"permissions": {"allow": ["Bash(PGPASSWORD=... psql -h db.example.com -U app)"]}}

The file is personal, and Git ignores it when Claude Code creates it. If it was created by hand, or added with git add before the ignore rule existed, it stays tracked and gets pushed. A tracked file is not removed by adding it to .gitignore later.

Several write-ups described this in November 2026 (Cloud Security Alliance research note, GitGuardian). The figure of 2,539 widely quoted from Apiiro's November 5 report counts secrets gathered from settings files, Git history and agent transcripts; not all of them are keys confirmed to be valid. For current copies of settings.local.json alone, the reported figure is 1,122 of 104,185 public files (about 1.1%). These are the company's findings as reported; we have not verified them independently.

2. Check your own repository

# list tracked AI configuration files
git ls-files .claude

# was it ever committed?
git log --oneline --all -- .claude/settings.local.json

# stop tracking it (the file stays on disk)
git rm --cached .claude/settings.local.json
echo ".claude/settings.local.json" >> .gitignore

A credential that reached history or a remote cannot be taken back by deleting the file. Revoke it at the issuer and create a new one.

For the contents, dropping the folder into the browser scanner is the quick way. It detects secrets inside the permission rules of .claude/settings.local.json and .claude/settings.json, the .claude/.credentials.json file, inline passwords such as PGPASSWORD=..., MYSQL_PWD=..., REDISCLI_AUTH=... and --password=..., and database URIs that carry a password. Obvious placeholders such as <password> or $DB_PASS are not reported.

3. Traces that end up in what you publish

When an agent works on your machine, logs, configs, error output and test results pick up details of that machine. Typical leftovers:

Kind	Example
Absolute home paths	`/Users/<login>/...`, `/home/<login>/...`, `C:\Users\<login>\...`
Keys	service API keys, anything starting `BEGIN ... PRIVATE KEY`
E-mail addresses	a contact line in a README, the commit identity
Image metadata	JPEG EXIF (can include GPS), PNG text chunks
Document authors	PDF `Author`, Office creator fields
OS residue	`.DS_Store`, `__MACOSX/`, `Thumbs.db`, `.env`
Git identity	commits made under a personal name and address

ZIPs are where this gets missed: people review the working folder, not the archive they built from it, and certainly not a ZIP inside that ZIP.

4. The gate

The policy is one line: if anything is found, the commit or push fails.

4.1 Known shapes: regular expressions

HOME_PATH = re.compile(
    r"(?<![\w.])(?:/Users/|/home/|[A-Za-z]:\\{1,2}Users\\{1,2})([A-Za-z0-9][A-Za-z0-9._-]*)"
)

The leading (?<![\w.]) keeps URLs such as https://example.com/home/dashboard from matching. Placeholder and CI names such as you or runner are allowed.

4.2 Your own name: read at run time, never stored

A scanner with your real name written in it is itself a leak. The gate reads the login name, the full name registered with the OS, and the global git identity from the machine on each run, matches in memory only, and masks them in its output.

raw.add(getpass.getuser())
raw.add(Path.home().name)
full = run(["id", "-F"])          # macOS: registered full name

Terms are searched as UTF-8 and as UTF-16, because Office files and some binaries store names that way.

4.3 Archives: open them all the way down

def scan_archive(self, where, data, depth):
    with zipfile.ZipFile(io.BytesIO(data)) as zf:
        for info in zf.infolist():
            self.scan_bytes(f"{where}!/{info.filename}", zf.read(info), depth + 1)

scan_bytes calls scan_archive again when a member is itself a ZIP. .docx and .xlsx are ZIPs too, so creator fields are read through the same path.

4.4 Images: walking segments is enough

Walk the JPEG segments; an APP1 segment that starts with Exif means EXIF is present, and tag 0x8825 inside it means GPS data. No imaging library needed.

4.5 Hooks

# .git/hooks/pre-commit
exec python3 gatekeeper/zero_trace_check.py --staged --identity

# .git/hooks/pre-push
exec python3 gatekeeper/zero_trace_check.py --all --identity --history --remote --path dist

Pre-commit scans exactly what is staged. Pre-push scans the whole tree, commit authors and messages, the remote URL, and the git-ignored folder where distributable ZIPs are built. The same check runs as the first job in GitHub Actions; publishing jobs depend on it.

5. Verification

A checker grading itself proves nothing, so a separate program builds a throw-away corpus of planted leaks and clean look-alikes and runs the gate over it. Planted values are assembled at run time, so the probe itself passes the gate.

Item	Result
Files with a planted leak	32 of 32 detected
Clean look-alikes	0 false positives out of 17
Time	about 12 to 18 ms across two runs (Python 3.14, Apple Silicon Mac, single run)

The planted set: inline passwords (the environment-variable form and --password=), a database URI with a password, AI settings files (settings.local.json itself, a token inside a permission rule of a shared settings.json, .credentials.json), BIP-39 recovery phrases (12 and 24 words), an EVM private key assigned to a key name, a Solana keypair file, an exchange API secret, absolute paths for three operating systems, four kinds of key and private key, an e-mail address, a hard-coded password, a JPEG with EXIF and GPS, a PNG with a text chunk, .DS_Store, .env, a PDF with an author, a ZIP containing a path, a ZIP inside a ZIP containing a key, a ZIP with __MACOSX, a truncated ZIP, a .docx with a creator, a binary holding a private term in UTF-16, and a file name containing a private term.

The clean set includes database documentation that holds placeholders only (<your-password>, $DB_PASS, changeme, user:password@localhost), a .claude/settings.json without secrets, a SHA-256 value (the same 64 hex digits as a key), ordinary prose that happens to use wordlist words, placeholder paths like /Users/you/, actions/checkout@v4, logo@2x.png, example.com addresses, a URL containing /home/, and code that only reads credentials from the environment.

The raw result is published as is: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/evidence/selftest.json

6. Limits

Free-form information is not detected. A real name or address in prose is only caught if it is a term read from the machine or one you added to the local deny-list.
Key detection covers common formats only.
Text visible inside an image is not read.
"Zero findings" means none of the shapes this gate knows are present. It is not a proof of safety.

The whole setup

The arrangement that moves the check from attention to a gate on your own machine, on one page. Numbers are measured in our own tests.

Summary

A command approved with "don't ask again" is stored as a literal string. Do not approve commands that carry a secret inline.
A tracked file is not removed by .gitignore. Check with git ls-files .claude, untrack with git rm --cached.
A credential that got out is revoked, not deleted.
Do the check at commit and push, not by attention. Open archives all the way down.

The browser scanner and a lite command-line report for text files are free: https://zero-trace-ship-kit.zeus-lab-global.workers.dev/?utm_source=devto

The free edition (lite command and local MCP server) is on GitHub: https://github.com/ZEUSLABZERO/zero-trace-lite

The full kit with the gate that blocks commit and push and the ZIP packager: https://zeuslab.gumroad.com/l/zero-trace-ship-kit?utm_source=devto

The full kit also includes a local MCP server so that Claude Desktop or Cursor can call the gate. It has no external package dependencies, but that does not remove supply-chain risk as a whole (Corelight reported in November 2026 that MCP server dependencies can change between rebuilds). Check the SHA-256 of what you download each time it is updated.

The estimate of cumulative input cost for agents, and the guard that refuses a call before it runs, now live in a separate post.

Disclosure: this article was drafted with AI assistance (Claude) and checked against the measured results and the published files. Product links lead to our own paid kits.