Jarroba Tools

IEEE-754 representation of a decimal number in 32-bit (single) or 64-bit (double): sign, exponent, mantissa, raw bits, hex, and the value actually stored.

Say which paths a `.gitignore` or `.dockerignore` ignores AND BY WHICH LINE — it is `git check-ignore -v` without git. And it does what no other tool does: it reads the SAME file as git and as Docker and points at where they do NOT decide the same. The two formats look alike and are not: a pattern with no slashes (`node_modules`) applies at any depth in git but ONLY at the root in Docker, so a `.dockerignore` copied from a `.gitignore` pulls into the build context exactly what you thought you had excluded. It also warns about the `!` that cannot work because its folder is already excluded, which is the number-one cause of "my exception does nothing".

IR drop across a power delivery grid: worst and mean voltage lost, and where the worst is. Solves the 2D resistive network (GV=I) with sparse conjugate gradient. Use it to compare frontside delivery (entry points further apart) against backside (spread out, lower-resistance metal) at the SAME load, which is the only comparison that means anything. First-order: uniform single-layer mesh, static and equal load per region, no inductive coupling, no switching. Real designs are signed off at 0.5-2.5 % of Vdd.

Structural differences between two JSON documents, by path: added / removed / changed / type changed.

Decode a JSON Web Token WITHOUT verifying its signature: header, payload and metadata (exp, iat…).

Run a NAMED metric from the semantic layer against RDF data: fills its {{param}} placeholders from `args` and executes the resulting SPARQL. Use it so "revenue" or "active users" is computed from the AGREED definition instead of a query you invented — the fix for "one number, three answers". Returns the effective SPARQL and the result, or which parameters are missing.

Run SPARQL 1.1 (SELECT/ASK/CONSTRUCT/DESCRIBE) over in-memory RDF — a real engine, not pattern matching. Accepts Turtle, N-Triples, N-Quads, TriG, JSON-LD or RDF/XML. Returns rows (SELECT), a boolean (ASK) or Turtle (CONSTRUCT/DESCRIBE).

Validate a SEMANTIC LAYER document (term→predicate glossary + named SPARQL metrics) before trusting it: structure, required fields (term/target, name/sparql), metric names usable as identifiers, and uniqueness. Returns {ok, errors, warnings}. This is "semantics as code": define once, compute the same everywhere.

Validate RDF data against its SHACL shapes (core subset): sh:targetClass + sh:path with minCount, maxCount, datatype, class and nodeKind. Returns whether it conforms plus every violation (node, property, constraint, message).

Understand a log without reading it: detected format, number of EVENTS (a 40-line stack trace counts as one), breakdown by level, time range, the errors with their ROOT CAUSE resolved, and the most frequent patterns. Accepts a file PATH — that is how you look at a log that does not fit in your context, such as a CI log of hundreds of MB.

What ELSE happened around a moment in time. Given an instant — the spike log_trends returned, or the time of an alert — find the patterns that cluster there and do not appear the same way in the rest of the log. Correlation is NOT causation, and what settles it is order: what started BEFORE comes first and is a candidate explanation; what came after is usually a consequence. Background noise is filtered out even when a narrow window lands on one of its bursts.

Convert a log from one format to another through OpenTelemetry's Logs Data Model: JSON, logfmt, syslog RFC 5424, CSV, OpenTelemetry or Elastic Common Schema. Tells you UP FRONT what the conversion loses — syslog only has eight severities and a text body, so coming down to it from JSON drops fields.

Check whether the log is WELL WRITTEN — not what happened in the system: secrets or personal data printed, one line flooding the file, timestamps with no time zone (which make two machines impossible to correlate), the clock going backwards, everything at the same level, no request id, payload dumps, and orphan stack traces with no error line. Every finding comes with its count and a sample; secrets are masked.

Group log lines into TEMPLATES (Drain algorithm): "connected to 10.0.0.1" and "connected to 10.0.0.7" are the same message. Turns a million lines into a few hundred readable things, each with its count, worst level and time range. Also returns the RARE ones (seen once or twice), which in a production log are usually what you were looking for.

Validate a Jarroba Tools LOG PROFILE (the `logprofile: 1` JSON that configures the log tools: format, server time zone, own-code prefixes, rules and AI budget). Returns ALL errors at once, each with the exact field (`rules[2].pattern`) and what was expected, so you can fix them in one pass instead of one at a time. Format documented in `public/logprofile.md`.

Propose a LOG PROFILE from a real log: infers the format, the own-code prefix (read from the stack traces, which is where it is demonstrated) and a starting set of rules covering the most frequent errors and whatever floods the file. What it does NOT propose is the server time zone: that is not in the log, and inventing it shifts the entire timeline without anyone noticing. Accepts a file path.

Cut a log down to a CHARACTER budget while keeping what matters: errors with their full stack trace, the window of what happened just before, and anything that appears only once or twice. Repeats are collapsed with their count ([xN]) and gaps are marked ([...N]). Use it to hand a big log to a model without spending the context on the same line repeated.

Put a folder or a list of rotated logs into TIME ORDER, split into series. Rotation numbering runs BACKWARDS against time: `app.log.3.gz` is older than `app.log.1.gz`, and plain `app.log` is the newest; alphabetically `app.log.10` sorts before `app.log.9` while in time it comes after. Use this BEFORE reading several logs of one service, or you will read them backwards. Returns the paths already ordered, ready to feed to log_analyze one by one.

Read an exception stack trace (Java/JVM, Python, Node, Go, .NET, Rust, Ruby or PHP) and answer the only question anyone asks it: WHERE TO LOOK. Follows the "Caused by" chain to the root cause, separates your code from the framework, and points at your first frame. Infers which package is yours from the trace itself if you do not say.

Answer WHEN IT STARTED, which is what a log is really asked. Compares each pattern against ITSELF rather than against total volume — in a busy service everything rises at 9am and nothing has happened — and returns three different things: what SPIKED relative to its own normal and at what time; what is NEW, which did not exist before and is usually what a deploy left behind; and what STOPPED APPEARING, which raises no counter and is often the worse news.

Generate a ready-to-use Makefile for a stack (node, python, go, rust, c or generic). What it generates PASSES its own linter with zero findings: it always ships `.DELETE_ON_ERROR`, `SHELL := /bin/bash` with `.SHELLFLAGS := -eu -o pipefail -c`, and declared `.PHONY` targets — the three lines that are almost never there and that prevent the most expensive failures. With `withLogs`, targets record their output through `tee`, redirect stderr, timestamp the file name, and take the log directory as an order-only prerequisite.

Review a Makefile and return the mistakes that actually bite, each with WHAT is wrong, HOW it breaks in practice and HOW to fix it: a recipe indented with spaces instead of a tab, a `cd` that does not persist to the next line, a `$` that make eats before the shell sees it, `$(shell ...)` inside a `=` variable (re-executed on every use), a pipeline without `pipefail`, a missing `.PHONY`, and a missing `.DELETE_ON_ERROR`. Calibrated NOT to complain about correct code: a well-written Makefile comes back with zero findings.

Compare the output of a REAL `make` run with what the simulation predicted, matching each command in the log to the Makefile rule that produced it. **What makes this useful, rather than any log analyzer, is the diff:** if make rebuilt something the simulation considered cached, that is the signature of an UNDECLARED DEPENDENCY — it raises no error, it just makes the build slower than it should be, or occasionally fails to rebuild what it should. Line-to-rule matching is APPROXIMATE and each match carries its confidence: recipes are echoed after variable expansion, a leading `@` suppresses them entirely, implicit rules produce commands that are not in the file, and with `-j` the output interleaves. make emits no timestamps, so nothing is said about how long anything took.

Answer the question that decides whether `make` is giving you anything: is this Makefile a BUILD, or a script LAUNCHER? make exists in order NOT to redo what is already done — mtimes, a dependency graph, skipping what did not change — and most Makefiles today use none of it: they are `make test`, `make lint`, `make docker-up`, all .PHONY, all running every time. Here each target is classified WITH THE SIGNAL that decided it (including the signals that pointed the other way: a .PHONY whose recipe creates that very file is a bug waiting to happen), what make is giving you TODAY is measured, and with `convertTo` it is converted to just, Taskfile or npm scripts. Whatever cannot be converted is OMITTED with its reason, rather than emitting a recipe that would look the same and rebuild every time. Honest caveat: `make` is POSIX and is everywhere; just and task have to be installed.

Simulate `make` WITHOUT RUNNING ANYTHING: which targets would be rebuilt, in what order, and WHY, naming the file to blame. Answers the two questions no other tool answers: "why is it rebuilding this when I changed nothing?" and "why is it NOT rebuilding it?". With `project` it reads the Makefile and the REAL mtimes from disk; `touch` asks "what if I changed this file?" without changing it. The reasons use the same vocabulary as the Linux kernel's `make V=2`.

Paste the `tools/list` response of an MCP server — yours, or a third party's you are evaluating whether to install — and check its catalogue quality: missing descriptions or annotations, a tool name that suggests it writes or deletes while its annotations say otherwise, context cost per tool (real BPE tokenization), and whether the top-level `instructions` field is set and fits under the ~2 KB some Tool Search clients trim. Add `serverJson`/`packageJson` to also catch the official MCP registry's own field-length and namespace-pattern limits, and a version mismatch between the two — the exact 422/403/400 errors this project hit publishing its own packages. This is NOT an access-security review: it does not evaluate what the tools are permitted to do, only how the catalogue is described.

Show an integer in binary, octal, decimal and hex, plus its bit view (signed/unsigned, popcount, leading/trailing zeros) at the chosen width. Accepts decimal, 0x…, 0b…, 0o…

Check a system prompt against the rules that make it followable: an explicit output contract, a definition of done, what to do when the model does not know (the rule that prevents made-up answers), contradictions, unverifiable requirements, prohibitions with no alternative, example count and context budget. It does NOT judge whether the prompt is GOOD — that needs evals and a real model run — it is the deterministic layer underneath. Useful on your own system prompt.

M/M/c queue: with N resources, how many people wait, how long, and what fraction leaves without a place. With `waitingRoom` the model becomes M/M/c/K (finite waiting area — the realistic case); without it the queue is infinite. Output times are in MINUTES. Erlang and M/M/c are exactly the kind of arithmetic a model does "from memory" and gets wrong.

Pure LOSS system (Erlang B): there is no waiting area, so whoever finds no free resource leaves. Car parks, workshop bays, phone lines, critical-care beds.

Simulate the queue customer by customer (discrete events, fixed seed, so the result is reproducible). Its job is to CROSS-CHECK the analytic answer: if the simulation and the formula disagree, one of them is wrong.

How many resources do you need? Returns the MINIMUM that meets your target (max wait, max turned away, or max utilization) and how the system behaves at that number. This is the question asked before building a place, not after.

Split a text on real boundaries (paragraph, else sentence, never mid-word) with the overlap you ask for, and optionally rank the chunks against a query with BM25. Use it to prepare a RAG corpus, or to see why a query fails to retrieve what it should. No model involved: this is the lexical half, the one that finds literal terms — a code, a surname, a version number — that an embedding dissolves.

Test a regex against a string: whether it matches, every match and its capture groups. Exact matching, not guessed.

Carrier concentrations in a doped semiconductor at a given temperature: n, p, band gap (Varshni), intrinsic concentration and Fermi level. The minority carrier is computed as ni^2/majority to avoid the catastrophic cancellation that destroys precision when subtracting nearly equal dopings.

Parse a SemVer version (major.minor.patch + pre-release + build metadata).

Given a list of versions, which ones satisfy a SemVer range (^, ~, >=, <, x, …).

Static noise margin (SNM) of a 6T SRAM cell by the butterfly method: two cross-coupled transfer curves and the side of the largest inscribed square. Returns the margin per mode (hold/read/write), the per-lobe split (which side would flip) and, optionally, the margin expressed in sigmas and the array failure probability. NOT the diagonal shortcut, which returns twice the correct value. First-order Shichman-Hodges: no body effect, no process variation, no parasitics — it shows why the margin moves, it is not a silicon signature.

SRAM read timing from dV = I*t/C: bit-line capacitance, signal needed, and how long before a 1 can be told from a 0. The signal needed is the amplifier sensitivity PLUS several sigmas of its offset, which usually dominates. Also returns the time for 1/2/4/8 banks. First-order: constant cell current, capacitance linear in cell count, no line resistance or column coupling. The reads-per-second figure is signal development only — a real read adds precharge, decoding and amplification.

Standard-cell geometry from its height in TRACKS: height, area, tracks left free for routing, fins per transistor, density and power-rail resistance — plus what you gain and lose against another height. The rail resistance it returns is what ir_drop consumes. Warns when the height does not land on the routing grid, which misaligns pins when alternate rows are flipped to share a rail. Idealised geometry: no real design rules, no vias, no parasitic extraction.

Escape a string for a target context: javascript, json, sql, regex, html, url or css.

Unescape a string from a context (javascript, json, sql, regex, html, url, css).

Audit a test file and say, case by case, what it ACTUALLY checks: which ones assert about a value, which only check that something exists, which assert nothing at all, and which are disabled. Returns the EVIDENCE behind each verdict (the assertions it found) so you can check the checker. TypeScript, JavaScript, Python, Java and Go. Executes nothing. Run it on the tests you just wrote, BEFORE you hand them over: told to "make the tests pass", widening a matcher is cheaper than fixing the bug, and this is what notices.

From a TYPE to the cases worth testing, with no model involved: equivalence partitions and boundary values derived from a TypeScript signature or a JSON Schema. For each parameter it returns the TECHNIQUE that applies and why — boundary values only mean something where there is an ordering, so they are NOT applied to a boolean or an enum. It adds the properties that can be asserted without knowing the domain, plus a fast-check test ready to paste. Use it BEFORE writing the tests, so you do not miss the cases everyone misses.

A project's DISABLED-test debt, WITH ITS AGE. Walks the folder, finds every `it.skip`, `xit`, `@Ignore`, `@pytest.mark.skip` or `t.Skip`, and dates it with `git blame`. None of those cases appears in a coverage report, because as far as the runner is concerned they do not exist: this is the debt nobody measures and the one that lasts longest — disabled 'to fix later', and later never comes. Sorted oldest first, which is what makes it actionable.

Compare TWO versions of the same test file and say whether the change STRENGTHENED or WEAKENED the safety net: widened matchers (toBe -> toContain -> toBeGreaterThan), assertions that disappeared, and cases that stopped running. Call it on your own work after touching tests, and above all after fixing a red suite: reaching green by softening an assertion is cheaper than fixing the bug, and this is what catches it. Executes nothing.

Try to decode a string from URL-encoding, Base64 and HTML entities.

Encode a string to URL-encoding, Base64 and HTML-escape (all three at once).

Convert an instant between formats: Unix (s/ms), ISO 8601, human, log, and per-locale/timezone. Accepts a Unix number or a date string.

Synchronous path analysis: setup and hold slack, and maximum frequency. The clock period appears ONLY in the setup check, so a setup failure is fixed by lowering the frequency and a hold failure is not — no speed makes it work. Skew enters both with opposite signs. With irDropV+vdd+vth it also derates the logic by voltage (alpha-power law), connecting power delivery to the clock. First-order: ONE path, delays as numbers, no process variation, no jitter, no temperature derating.