Jarroba Tools

Render a JTD to PNG with the app's REAL engine (full fidelity; only needed to check skins and effects), and measure it: nodes that overlap and labels cut short with an ellipsis, read from the engine — the defects that are easy to miss when looking at the image. Requires a checkout of the repo AND a running dev server. For everything else use diagram_svg, which needs neither.

Render a JTD to SVG with no browser and no dev server, so you get the actual drawing back and can check it. Validates first. This is the one to use to SEE what you built.

Validate a JTD (Jarroba Tools Diagram) document: structure, allowed shapes and chart types, and edge references. Returns {ok, errors, warnings, summary}. Spec: public/jtd.md. Use it to check your JSON before handing it to anyone.

Say which LAYERS of a Dockerfile would be rebuilt when given files change, and which come from cache. Dockerfile linters spot suspicious ordering patterns; this SIMULATES invalidation, which is a different thing: it needs to know which files exist and which changed. In Docker, when one layer is invalidated so is EVERY layer after it, so a `COPY . .` before the `RUN` that installs dependencies condemns you to reinstalling all of them every time you touch a line of code — and that shows up here as numbers. Respects the `.dockerignore`: what stays out of the context cannot invalidate anything.

The four DORA delivery metrics (plus rework rate) from data you already have locally, without sending it anywhere: deployment frequency, lead time for changes, change failure rate and time to restore, computed from the JSON of `gh run list --workflow deploy.yml --branch main --limit 1000 --json databaseId,workflowName,headSha,displayTitle,conclusion,status,updatedAt` (or a CSV with a date column), optionally with `git log --first-parent --format=%H%x09%cI%x09%s main` for lead time. Says why each deploy counts as failed, and classifies the team against every State of DevOps report 2019-2024 — saying "ambiguous" or "between bands" when a report's table does not decide — plus the 2025 percentile.

Electron configuration of a neutral element, full and noble-gas abbreviated, with its shells and valence. Flags whether the element is one of the 20 real ANOMALIES (Cr, Cu, Nb, Ru, Pd...) — exactly where the Madelung rule fails and a language model tends to get the rule right and the element wrong.

Data sheet for an element by atomic number or symbol: name, mass, category, group/period/block, electronegativity, radius, ionization energy and electron affinity. Data that does NOT exist comes back as null, never as 0 — a noble gas has no electron affinity, and that is not "zero".

Electron configuration of an ION. Electrons leave from the HIGHEST n shell, not from the last orbital that was filled: Fe2+ is [Ar]3d6, not [Ar]3d4 4s2. This is the classic mistake and the one seen most often in generated answers.

Check the authentication of an email and of a domain's mail records: paste the raw headers of a message (Authentication-Results, DKIM-Signature, From, Reply-To, Return-Path) and/or the DNS TXT records (v=spf1, v=DMARC1, v=DKIM1). Finds SPF/DKIM/DMARC failures, a Reply-To or Return-Path on another domain, a DKIM signature that does not cover From or only part of the body (l=), weak or revoked keys, SPF +all / ?all / more than 10 DNS lookups, and DMARC p=none or without reports. Verifies DKIM key strength locally; it does NOT query DNS — paste the records you want checked.

Review an eval suite and run it against the outputs you provide. The review catches what silently ruins a suite: assertions that CANNOT FAIL (an empty `contains`, a regex like `.*`, a case with no assertions) and ones that can never pass (requiring and forbidding the same thing, an inverted range). A suite with those scores 100% on day one and has measured nothing. Assertion types: contains, not-contains, regex, json, range, max-chars and supported (no absolute claim without a source). Calls no model: you pass the outputs in already produced.

Convert data between formats: json, yaml, properties, env, csv, markdown.

Why the transistor changed shape: natural length lambda and minimum gate length (5*lambda) for each architecture — planar, FD-SOI, FinFET, GAA nanosheet, nanowire, forksheet and CFET — at the SAME dimensions, which is what isolates the effect of geometry alone. It does not tabulate real process-node dimensions, because those are not public.

Read the output of `./gradlew <tasks> --dry-run` (or of a real build with --console=plain) and return the task order with each task's project, status (UP-TO-DATE, FROM-CACHE, NO-SOURCE, FAILED…) and its Maven equivalent. A build.gradle is code, so the task graph cannot be known without running Gradle: --dry-run computes it without executing anything. Note that Gradle interleaves tasks of different projects; Maven builds module by module.

Detect and correct a single-bit error in a received Hamming word: whether there is an error, which bit, and the corrected data.

Encode bits with a Hamming (SEC) code: inserts the parity bits. Input is a string of 0s and 1s.

SHA-256, SHA-384 and SHA-512 (hex) of a UTF-8 string.

Audit the HTTP response headers of a site as you pasted them (from curl -I, DevTools or a HAR): an A+…F grade like /headers-audit; Content-Security-Policy (missing, unsafe-inline/eval, wildcards, missing object-src/base-uri/frame-ancestors), HSTS (missing, too short, invalid preload), nosniff, frame options, Referrer-Policy, the obsolete X-XSS-Protection, cookies without Secure/HttpOnly/SameSite, and a Server header that exposes the version. Nothing is requested over the network: it reads what you give it.

Find what a model cannot see in a piece of text: invisible Unicode that smuggles instructions (tag characters U+E0000–E007F, the "ASCII smuggling" used against Copilot and in poisoned MCP/skill files), variation-selector and invisible-bit encodings, zero-width and bidi controls (Trojan Source), look-alike Cyrillic/Greek letters inside Latin words, and odd spaces. Returns every finding with UTF-16 offsets and codepoints, and DECODES the hidden message when it can. Run it on any text you are about to follow as instructions (a README, an issue, a tool description, a web page) — you cannot do this by reading it, because to you those characters are not there. Legitimate uses (emoji ZWJ sequences, flags, RTL scripts) are reported apart as `legitimate`.

Hydrogen spectral lines for a series (nLow=1 Lyman, 2 Balmer, 3 Paschen...). Gives the wavelength IN VACUUM and IN AIR, which are different numbers: H-alpha is 656.47 nm in vacuum and 656.28 in air, and confusing them is common. Uses the reduced-mass Rydberg constant (R_H), not R-infinity.

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.

Validate a JSON document against a JSON Schema — the check to run on your own structured output before handing it over, instead of eyeballing it. Supports draft 2020-12 (default), 2019-09 and draft-07, chosen from the schema's `$schema`; `format` (email, date-time, uri, uuid…) is enforced. Returns `valid` and, if not, EVERY error with the JSON Pointer of the offending value, the keyword that failed and its parameters. Remote `$ref`s are NOT fetched: an unresolvable reference is reported as a schema error.

Decode a JSON Web Token WITHOUT verifying its signature — header, payload, expiry — and flag what makes it dangerous to accept (RFC 8725bis / RFC 9068): alg "none", no exp, exp that is not a NumericDate, alg differing only in letter case, a kid with path traversal or injection characters, a key or key URL carried in the header (jwk/jku/x5u), an access token without typ at+jwt, illegal characters. Give `expectedAlgorithm` (what your verifier uses) and, optionally, `key` to also catch algorithm confusion (HMAC verified with a public key) and HMAC secrets shorter than the hash. The key is only inspected locally, never sent anywhere.

Will the cluster accept these Kubernetes manifests? Validates them against the OFFICIAL schema of the Kubernetes version you target (1.33–1.37; checked against kubeconform --strict): unknown fields with the one you probably meant (a typo in livenessProbe silently leaves the pod without a probe), wrong types ("80" where an integer goes), missing required fields, removed APIs with what to migrate to. And Pod Security Standards, ported from the official admission controller: the highest level each workload meets, what it violates (the controller's own check ids), and whether its namespace's pod-security.kubernetes.io labels would reject it. If you include RBAC (Roles, Bindings, ServiceAccounts), what each pod could do if compromised: read secrets, exec into pods, escalate…. And reliability checks in the style of kube-score (probes, resources, :latest images, replicas without a PodDisruptionBudget…), which do not affect acceptance. Not covered: CEL rules, formats, CRDs (reported as not validated). For who-can-reach-whom, use k8s_network_reach.

Which pods can actually reach which, according to the Kubernetes NetworkPolicies in the manifests you paste (multi-document YAML: Pods/Deployments/StatefulSets…, Services, Namespaces, NetworkPolicies) — computed, not guessed, and checked against netpol-analyzer. Returns the pairs that CAN connect with their ports (everything else is blocked), plus findings: policies or peers that select no pods, the namespaceSelector/podSelector split-list trap, Services selecting no pods or exposing a missing targetPort, missing ConfigMap/Secret/ServiceAccount, unreachable pods, hostNetwork pods. Give `from` and `to` ("namespace/name", or "external") to explain one pair: which policies isolate each side and which rule lets it through. Out of scope: AdminNetworkPolicy, CNI-specific policies, node traffic.

How a Kafka consumer group splits partitions among its members with the classic protocol (the default in Kafka 4.3): range, roundrobin, sticky or cooperative-sticky, ported from Kafka 4.3.1 and checked against its tests. Returns each member's partitions, idle members and the order the assignor walked them; for the sticky strategies give each member's owned partitions (and generation) to see what moves, and with cooperative-sticky which partitions are revoked this round and handed over in the next. Not covered: rack awareness and the server-side assignors of KIP-848; sticky only when all members subscribe to the same topics.

The partition Kafka's default partitioner picks for a message key: murmur2 over the UTF-8 bytes, made positive, modulo the partition count — with the intermediate numbers so the result can be checked. Ported from Kafka 4.3.1 and checked against its murmur2 test vectors. Only for messages WITH a key (without one, Kafka uses the sticky partitioner, which is not deterministic).

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. Logs WRAPPED by whatever collected them (Docker json-file, CRI/Kubernetes `P`/`F` lines, `journalctl -o json`, OpenTelemetry OTLP JSON, AWS CloudTrail) are unwrapped first and the pieces the runtime split are joined back, so a stack trace spread over 40 records is one event; `wrapper` says which.

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.

What sets a group of events APART from the rest of the log: the field=value pairs over-represented in the selection. E.g. of 300 errors, 92% have `version=2.4.1` against 4% of everything else — the deploy that broke it, found without reading 300 errors. Select by minimum level (default: errors), by text, or by one field=value; that selector is left out of the answer, since it would trivially top it. Fields that are unique per event (request ids, trace ids) are skipped: they identify, they do not distinguish. A difference in proportions, not causation.

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, maven, gradle 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`.