// hello retard

code last updated early august 2026

artifact The deliverable is exactly one Hypertext document (example: a single index.html). No companion application server of our own, no required build toolchain for basic use, no installable package store dependency for core function.

client-side execution Logic runs in the visitor's user agent (example: scripts inside the page). Work that needs a machine you do not control is out of scope unless it uses only optional, public, key-free network endpoints (examples: a public IP echo service; a public DNS-over-HTTPS resolver that allows browser requests).

main-thread execution Logic for this artifact runs on the page's main script turn unless a progressive browser engine already does work off-thread on its own (examples: Web Audio rendering; crypto.subtle where the user agent schedules it). Authors must not add background script workers (examples: Worker, SharedWorker, or worker-style worklets introduced to move toolkit logic off the main thread) unless this Rules text is changed to allow them. The restriction preserves a single, inspectable execution model, avoids multi-file worker sources, and keeps session release and memory clear behavior simpler to reason about. STORAGE_KEY_REGISTRY lists every localStorage/sessionStorage key this file’s product tools write by design (Origin Storage Manager may also write operator-chosen keys outside that list). Trace Wipe clears all localStorage and sessionStorage on this origin, not only registered keys. Heavy work stays on the main thread (no author-added workers unless this Rules text is changed). Prefer smaller steps and visible status when practical. Do not impose permanent hard file-size ceilings that refuse work merely because an input is large—what a tab can finish depends on the user agent and device and changes over time. Do not use modal dialogs (confirm / cancel) to gate size or memory risk. Do not substitute a size/risk sermon in a result box for the tool's normal output. Size and memory risk belong in each affected tool's explanation ([?] / Cannot / Likely errors): very large inputs may slow, hang, or crash the tab; recovery is reload (clear cache if needed), reread [?], and retry with judgment. Assume a competent operator; ship full capability. Static tools do not self-upgrade—humans adapt usage. Prefix or bounded reads are allowed only when that is the tool's purpose (example: header triage), not as a global max-file product ban. This entry does not forbid ordinary asynchronous page APIs (fetch, promises, timers) or the user agent's built-in parallel engines.

credential absence No service account, API key, bearer token, or password for a third-party product is embedded in the file. Features that cannot operate without such a secret are rejected.

browser baseline The page targets the popular user agents on the relevant device classes — not one brand chosen for taste. Device classes in force now: mobile (handheld general-purpose phones and similar) and computing (general-purpose desktop and laptop class machines). Further classes may be named later if they become central. "Popular" means high real-world use in the period on those classes (examples: major browsers shipped with or dominant on large phone platforms; Chrome and other high-share browsers on Android; major multi-platform browsers on computing devices). Where several agents each hold large share, the baseline is the set of them, not a single winner-take-all name. A feature absent from a baseline agent may ship only as progressive enhancement (examples: feature-detected, labeled in the tool explanation, optional, never required for the rest of the page).

progressive enhancement Extra capability layered on top of a working core (example: a serial-port tool that appears on a baseline-capable desktop browser but simply reports "not available" on a baseline mobile browser). The core path must remain usable without that extra capability. That same obligation supports closed-loop durability: a frozen baseline-class browser must not need a progressive-only API to use the offline majority of the page.

interface discipline Always-visible chrome at the top (identity, public IP when network allows, device meta). Everything else sits under a single "more tools" accordion. Inside it, tools are sorted into a small set of category groups so a person can find a tool in one or two opens. Search under more tools, when present, matches names in the live tree. Each tool carries an explanation panel with Simple, Advanced, and Cannot (and, where useful, Likely errors). Clearing applies to files, results, and previews that need cleanup; ordinary typing fields are not forced to carry clear buttons. Destructive clears ask for confirmation.

category groups Category titles name the job a visitor is trying to do, not the library or API used to implement it (examples at time of writing: Text & Documents; Photos, Video & Audio; Files & Evidence; Passwords & Encryption; Network & Web; Location & Time; Binary & Firmware; Origin · Runtime · Blueprint). Placement follows the job: media tools with media; integrity and field-check tools with evidence or files; codecs and obfuscation helpers with other transform utilities; device positioning with location. Do not place a tool by where the editor happened to insert the markup. Moving a tool between groups does not change its data-intent. After large moves, regenerate Tool Inventory · Intent Map from the live page so any blueprint paste matches the DOM.

hub panels When several views share one input or one evidence story, they may live in a single panel with modes or sections (examples: File Lab for identity, hex, strings, entropy, and pattern search; Evidence Package for build and verify; Location for capture and coordinate math). The panel keeps one stable data-intent for the hub. Split panels remain correct when the definition of a change or the failure mode differs enough that a shared shell would mislead (example: document-level diff versus line-level diff).

source comments HTML and script comments are optional notes for editors. They are not the contract, not a second inventory, and not required for the page to run. The live category titles, data-intent values, Rules, and Tool Inventory · Intent Map are authoritative for structure. Do not invent load-bearing behavior that only exists inside a comment.

edit discipline This artifact is one document with one primary script block. Structural HTML edits shift character offsets. Any script cut-and-join must re-locate the live <script> boundaries after HTML changes, then verify parseability before treating the file as ready (example: a syntax check on the extracted script). Prefer small, reviewable batches of tool or category changes over a single large dump that is hard to reverse if the join is wrong. Structural consistency is part of readiness: matched open and close tags for panels and groups, a single script element, stable data-intent values, and the same explanation shape (Simple, Advanced, Cannot, and Likely errors where useful) on tools that expose that pattern. Formatting here means reliable structure and naming—not a preferred pretty-print style. A file that looks tidy but fails to parse is not ready. Large cleanups still follow this entry: re-bind script by live tags, verify parseability, and do not trade user-visible behavior for a shorter file (see substance over housekeeping).

closed-loop durability The artifact is meant to remain useful without an update channel. A copy opened years later on a device and browser class comparable to the baseline at the time of authorship should still run its offline majority without contacting the author, a package registry, a CDN of libraries, or a forced upgrade path. There is no supported "phone home for a newer build" mechanism inside the file. Dependencies that the page cannot carry as itself are out of scope (examples: installable app stores, mandatory native companions, keys that expire and cannot be replaced locally). Optional public network endpoints may die or change; tools that use them must fail clearly and must not be required for the rest of the page to work. Prefer web-platform APIs already common on the baseline over APIs that exist only on one engine. Progressive enhancement may add capability when present; it must not make the core path depend on future platform gifts. Authors and later editors accept that "runs with zero issues forever on every future OS" cannot be promised for any software. The design obligation is stricter and narrower: no intentional need to update this file in order to keep using the offline toolkit on a frozen baseline-class browser; no hidden external runtime; degrade or label when an optional API is missing.

network honesty Any use of the public internet is visible in principle (examples: fetching a public IP; DNS-over-HTTPS; RDAP). Offline use must still allow the majority of tools to function. Header identity digs (public IP, latency, WebRTC leak row) wait on the dot countdown and can be blocked or started from that control; other network tools only contact the net when you run them.

single-document packaging Distribution is the Hypertext file itself (example: download or host index.html). Use Download · Copy This Page under Origin · Runtime · Blueprint to save HTML or a ZIP (STORE) of the served bytes when the network path works. Multi-file application frameworks, mandatory bundlers, or "install our app first" steps are outside this artifact's definition of ready-to-use.

secret material Credentials and private API keys are not part of the document (see credential absence). A feature that only works after "log in to our server" cannot exist here because no such server is part of the artifact.

scope of control The page may use interfaces the user agent exposes for this origin and this tab (examples: camera after permission; files the user selects; storage for this site). It does not administer the whole device or other sites (examples: it does not clear another origin's data, control global browser cache, or report true OS process memory as a system console would).

sensor and capture consent Sensors and recorders run only after the user agent's permission flow and only while this document's logic keeps them on (examples: camera, microphone, motion). Silent or background capture outside what the browser allows for a normal page is outside scope.

baseline honesty A capability that fails the browser baseline test is documented as limited or optional (see progressive enhancement). Advertising a non-baseline feature as if every supported user agent had it violates this rule.

professional substitution Tools on this page may support education, notes, calculation, and evidence handling. They are not a substitute for licensed clinical care, legal process, emergency services, or certified measurement instruments (examples: a tilt readout is not a diagnostic goniometer; a dose calculator is not a prescribing system). It is also true that many dependable practices began as crude methods. When formal systems are unavailable or untrustworthy, simple local tools can still be a practical last resort. That does not upgrade them into professional authority; it only states why keeping them honest and usable still matters.

platform evolution Browser capability changes over time (example: an interface that was rare on mobile later becomes common). This file is allowed to gain features when the browser baseline catches up, and required to keep progressive enhancement for anything still uneven.

capability revisit Re-check gated interfaces on a schedule or before a major edit — do not assume last year's "unsupported here" is permanent. Procedure: (1) open Where to Look hubs and engine status pages; (2) run Capability Watch in this page on each baseline agent you care about; (3) if a probe flips from missing → present on a baseline agent, wire or widen the matching tool with feature-detect + labels, never with a hard "Chrome only" lie; (4) update the tool's explanation Cannot/Advanced lines to match reality; (5) rebuild Blueprint Text so the inventory stays truthful.

capability registry Progressive APIs used in this file are listed in one script registry (Capability Watch). Humans and automated editors should add new gated APIs there when introducing them, so future probes and search instructions stay complete without scavenger hunts through the whole script.

data-intent Each tool panel may carry a stable purpose label (example: data-intent value local-crypto ). Blueprint Text, in-page jumps, and Capability Watch use these labels. When adding a tool, set a unique intent; when renaming purpose, update the attribute and any jumps or registry rows that point at it. Result boxes use data-export="text" or data-export="none" per result export.

capability registry maintenance Progressive or gated browser APIs used by this file are declared in the script array CAPABILITY_WATCH . Adding a new gated API without a new row there leaves probes and "find in source" guidance incomplete. Detect functions must be safe to run on every baseline agent (feature-detect only, no throws into the void).

file preview and object URL cleanup File inputs that drive canvases or media previews register cleanups with registerFilePreview(fileInputId, fn)(or data-preview-canvas). Temporary blob links created for downloads or previews go through trackObjectURL. Session release and related clears expect that discipline; skipping it looks like "Clear did nothing" or leaked blob URLs.

cross-panel session state Some tools share in-tab memory rather than imports (example: RSA/ECDSA key material kept in the same tab for local sign/verify tools). Closing the tab clears it. Not a server-side session.

cross-panel composition When a tool builds, verifies, or orchestrates work by reading another panel's inputs, outputs, or session state on this page (examples: stitching Markdown source, a custody log, and a hash manifest into one downloadable note; a macro that starts wake lock, tone, and speech already exposed elsewhere), the explanation must name those source tools by their live titles and must include in-page jumps (inpage-jump with the matching data-jump-intent) to those panels. The composite tool remains a separate data-intent; it does not replace the sources. A composite must not alter the underlying tools' fields, results, files, or session UI as a side effect of running: it may read their current values and write only to its own outputs. After using the composite, the operator should not need to clear or restore the source panels because of that run. Shared in-tab key material without a second panel UI (example: RSA keys held only for sign/verify on the same panel set) is covered by cross-panel session state, not this entry. Do not imply a server-side pipeline or a hidden second file.

in-page jumps Links with class inpage-jump and data-jump-intent="local-crypto" (example) open nested groups and scroll to the matching data-intent panel without putting a #hash in the URL. Ordinary href="#id" links are different: they use the URL fragment. Prefer inpage-jump for tool-to-tool navigation inside this file.

explanation audience and depth Explanations on this page (Rules entries, tool "what this does" panels, and similar instruction text) are written so a person with little background can learn what the control is for, how to operate it, and what failure or refusal looks like, while a person with more background can learn the real limits, main mechanisms, and conditions under which the result is incomplete or misleading. Those layers should agree. The plain-language part must not promise something the detailed part takes back; the detailed part must not describe a different tool than the plain-language part introduced. Where a tool is unavoidably specialist, the plain-language part may be shorter and may say that care or prior knowledge is needed; it should still state purpose and the important cannot or failure cases rather than only naming an API. When there is a trade-off between a shorter explanation and a more complete one, completeness of the expanded panel takes priority over brevity. That panel is collapsed by default; putting detail behind it is preferred to omitting limits, failure modes, or conditions that would change what a careful reader decides to trust. Brevity remains appropriate for labels, button names, and on-screen status lines—not as a reason to leave important limits out of the expanded explanation. This entry does not require maximum length on every panel, equal length across tools, or that every reader will fully understand every tool. It is a writing standard for this artifact: aim for cross-readable honesty, and when something important would be cut only "to keep it simple," keep that material in the expanded explanation rather than a beginner-only gloss or an expert-only note. Explanations that misstate live behavior stay in scope under substance over housekeeping; short is allowed, wrong or hollow is not. An explanation must not describe controls, menu options, modes, outputs, or side effects that this panel does not actually provide (example: naming a spread type or “max profit” readout that is not on the form). When the live UI is narrower than a general technique, say what is on the panel; put wider techniques only in Cannot or omit them.

assistive use without formal compliance This artifact is written so a person can operate it from the visible chrome and the expanded explanations, and so another person or an automated assistant can read those same labels, intents, and panels and explain or step through a tool. Prefer ordinary, named controls (examples: <button type="button"> for actions) over unlabeled clickable decoration when the control is the only way to run a tool. Keep purpose, limits, and failure modes in the explanation pattern already required under explanation audience and depth. This entry is not a commitment to any formal accessibility standard (examples: WCAG; programs commonly abbreviated a11y), continuous accessibility audits, or a full assistive-technology test matrix. Specialist or progressive tools may remain harder to use when the underlying browser API is limited. Dim or secondary text used only for hierarchy is allowed. Do not treat third-party accessibility checklists as Rules obligations for this file.

output over ornament A tidy edge is a weak reason to hide the end of a hash, path, error, or instruction.

result export Text export rows (TXT/MD/RTF/PDF) attach only to result boxes marked data-export="text". Status or caption boxes next to a canvas, file, or other primary artifact use data-export="none" (clear may still apply). Generic helpers follow the product, not every output-box class name. name alignment When an explanation or instruction names another tool or category on this page, that name should match the live title or category summary as shown in the interface (and in Tool Inventory · Intent Map). Prefer the current panel title over older or informal names after merges and renames. This entry does not require a second hand-maintained name table; the visible titles and category summaries are the reference. Update cross-references when a title or group name changes.

substance over housekeeping This file exists to run its tools under the Rules. Editors must not classify broken markup, dead handlers for removed controls, false labels, or explanations that misstate live behavior as residual, cosmetic, or inconsequential. If it affects what the user sees, trusts, or can do, it is in scope. Anything with no legitimate reason to remain—no user-facing path, no Rule obligation, no required dependency for a tool that stays—should be removed or replaced with a smaller dependency that still fully serves that tool. Efficiency means fewer moving parts and less dead weight, not stripping behavior. After merges, do not keep parallel leftovers, listeners bound to controls that no longer exist, or second name lists beside the live titles. Do not treat a progressive-enhancement path as dead weight only because it is absent on one baseline agent; if it is offered, it stays feature-detected, labeled, and optional under progressive enhancement and baseline honesty. Housekeeping (formatting, comment accuracy, guard style, quote normalization) is expected when it reduces confusion or risk, and only when it does not reduce behavior. Prefer a noisier but correct path over a cleaner path that drops a fallback, label, clear control, progressive-enhancement branch, or error message the user might need. Prefer small, checkable edits under edit discipline over one large cleanup that is hard to verify or reverse. Explanations and labels must stay aligned with live tools and name alignment, and must meet explanation audience and depth (plain and detailed layers agree; depth wins when brevity would omit a limit). That is not a demand for maximum length on every panel or identical depth on every tool. “Not important enough to fix” is invalid when the defect is real. “Cleaner code” is invalid when it weakens a function. “Leave it, it’s fine” is invalid when the code has no job. The artifact must not carry extra purpose beyond the tools and Rules, and must not operate under them by shipping known present breakage or silent gaps in what a tool claims to do.

defensive fit Guards and other defensive code belong where a real failure mode exists: a node that may be absent after a merge or on a progressive path, an API that may be missing, a permission that may be denied, an init order that can throw if reshuffled. They are part of keeping tools and boot reliable under the Rules. Defensive code is not a style goal on its own. A check that cannot fail on this page as built, and does not protect against a failure mode the architecture allows, is noise: it adds weight without serving a tool or a Rule. Prefer the smallest guard that matches the real risk. “Not failing for users right now” does not make a known footgun out of scope if a normal edit, merge, or path can still hit it. Present stability is not a reason to leave an order or null hazard that can take down boot or a tool path. Present stability is also not a reason to carpet-guard every property access where no such hazard exists.

authority of these entries These entries describe this file's design contract. They do not rewrite public law, hospital policy, or the specifications of the web platform. When platform facts change, the hubs under "Where to Look" outrank any stale example in this text. When two entries appear to pull in different directions, read them together (example: substance over housekeeping does not override progressive enhancement or closed-loop durability; it forbids both dead weight and cleanup that weakens tools).