@blamejs/blamejs-shop 0.0.44

package/lib/vendor/blamejs/CODE_OF_CONDUCT.md

@@ -0,0 +1,86 @@
+# Code of Conduct
+
+## Our pledge
+
+We as members, contributors, and maintainers pledge to make participation in the blamejs project a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+We pledge to act in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+## Our standards
+
+Examples of behavior that contributes to a positive environment:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+- Engaging in technical disagreement on the substance, not the person
+
+Examples of unacceptable behavior:
+
+- Trolling, insulting / derogatory comments, personal or political attacks
+- Public or private harassment
+- Publishing others' private information (physical or electronic) without explicit permission
+- Sexualized language or imagery, sexual attention or advances of any kind
+- Persistent disruption of discussions
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Scope
+
+This Code of Conduct applies in all project spaces, including:
+
+- The GitHub repository (issues, pull requests, discussions, comments, commit messages)
+- Any official communication channel the project operates
+- Public spaces when an individual is representing the project (e.g., presenting at a conference, posting on social media as a maintainer)
+
+It also applies to contributor behavior outside project spaces when that behavior has a direct impact on community members' ability to participate in the project safely.
+
+## Enforcement responsibilities
+
+Project maintainers are responsible for clarifying and enforcing this Code of Conduct. They will take appropriate and fair corrective action in response to any behavior they deem inappropriate, threatening, offensive, or harmful.
+
+Maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned with this Code of Conduct. They will communicate reasons for moderation decisions when appropriate.
+
+## Reporting
+
+If you experience or witness behavior that violates this Code of Conduct, report it to:
+
+**`conduct@blamejs.com`**
+
+All reports will be reviewed and investigated promptly and fairly. The maintainer team is obligated to respect the privacy and security of the reporter of any incident — reporter identity is shared only with the maintainers handling the report unless the reporter explicitly consents otherwise.
+
+Reports should include:
+
+- A description of what happened
+- Where and when it happened (link to the issue / PR / message if applicable)
+- Whether the behavior is ongoing
+- Any other context you think is relevant
+
+## Enforcement guidelines
+
+Maintainers will follow these guidelines in determining the consequences for any action they deem in violation:
+
+### 1. Correction
+**Impact:** Use of inappropriate language or other behavior deemed unprofessional or unwelcome.
+**Consequence:** A private, written warning, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+**Impact:** A violation through a single incident or series of actions.
+**Consequence:** A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
+
+### 3. Temporary ban
+**Impact:** A serious violation of community standards, including sustained inappropriate behavior.
+**Consequence:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
+
+### 4. Permanent ban
+**Impact:** Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
+**Consequence:** A permanent ban from any sort of public interaction within the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder.
+
+For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq.

package/lib/vendor/blamejs/CONTRIBUTING.md

@@ -0,0 +1,156 @@
+# Contributing to blamejs
+
+Thanks for considering a contribution. blamejs is a security-first framework with strong stylistic and architectural defaults — this doc is the operator's guide to making your patch land cleanly.
+
+## Quick links
+
+- **Found a bug?** Open an issue with the bug-report template. For security bugs, **don't** open a public issue — see [SECURITY.md](SECURITY.md).
+- **Have a feature idea?** Open a feature-request issue first to discuss the design before writing code. See "Ship complete, not incremental" below for why this matters.
+- **Want to ship a fix?** Read [Development setup](#development-setup), [House rules](#house-rules), and [The PR loop](#the-pr-loop) below.
+
+## Development setup
+
+```bash
+# 1. Clone + install (zero npm runtime deps; this only fetches dev tools)
+git clone https://github.com/blamejs/blamejs.git
+cd blamejs
+npm install --no-package-lock
+
+# 2. Run the full test suite (5000+ checks across 4 layers)
+node test/smoke.js
+
+# 3. Run the wiki example app's e2e (boots the wiki on an ephemeral port)
+cd examples/wiki && rm -rf data data-e2e && node test/e2e.js
+
+# 4. Run lint as a pre-commit gate (CI runs all three)
+npx eslint@latest --max-warnings 0 .
+docker run --rm -i hadolint/hadolint < examples/wiki/Dockerfile
+shellcheck $(git ls-files '*.sh')
+
+# 5. Optional: bring up the integration-test fixture stack and run live tests
+#    against real backends (redis / postgres / mysql / mongo / minio /
+#    rabbitmq / nats / syslog / ntp / mailpit / coredns + haproxy / caddy /
+#    mitmproxy / squid). Skipped by smoke; opt-in for changes that need to
+#    validate against real services with strict TLS verification.
+docker compose -f docker-compose.test.yml up -d --wait
+node scripts/test-integration.js
+docker compose -f docker-compose.test.yml down -v
+```
+
+**Requirements:** Node.js 24.14+ (current active LTS, fixes CVE-2026-21713 non-constant-time HMAC compare). The framework targets `node:sqlite`, `Intl.PluralRules`, modern `crypto` primitives, and other recent built-ins. Anything older is out of scope.
+
+## House rules
+
+These are the project's hard rules. Patches that violate them get bounced regardless of how clean the code is.
+
+### Zero npm runtime dependencies
+
+Every dependency is vendored under `lib/vendor/` with a manifest pinning version + license + provenance. Operators audit their dependency graph from `lib/vendor/MANIFEST.json`, not from `node_modules`.
+
+If you need a new external library:
+
+1. **First, check if you really need it.** The framework reaches for stdlib + Web Crypto + `node:sqlite` first. A dep is the last resort.
+2. If the answer is yes, vendor it via `scripts/vendor-update.sh <package> [version]`. This bundles with esbuild, copies to vendor dirs, updates the manifest, and removes the npm package itself.
+3. Document why in the patch's commit message. Reviewers will push back hard.
+
+### Post-quantum crypto only
+
+Every crypto operation uses PQC from the start: ML-KEM-1024 + P-384 ECDH (hybrid KEM), XChaCha20-Poly1305 (cipher), SHAKE256 (KDF), SHA3-512 (hash), Argon2id (passwords), SLH-DSA-SHAKE-256f / ML-DSA-87 (signatures).
+
+No classical-only fallbacks. No SHA-256, no AES-GCM, no P-256 ECDH-only, no Ed25519 outside the hybrid context. If you're adding a new encrypted blob format or signature surface, follow the algorithm-ID-in-envelope-header pattern (see `lib/crypto.js` and `SECURITY.md` → "Cryptographic stack").
+
+### Audit chain on every operator action
+
+Login, password change, page edit, key rotation, seed apply, vault seal — every operator action emits to the audit chain. The 5 W's (WHO / WHAT / WHEN / WHERE / HOW) are mandatory; the framework's `audit.safeEmit` enforces shape at the call site.
+
+Every namespace must be registered (`audit.registerNamespace("foo")`) before first emission. The smoke test at `test/layer-0-primitives/audit-framework-namespaces.test.js` walks `lib/` for emission patterns and fails CI on any missing registration.
+
+### Code style
+
+- **CommonJS only.** `require()` / `module.exports`. No ES module syntax in `lib/` or in `examples/wiki/`. The framework targets Node's CJS resolver because that's what the vendored bundles produce.
+- **`var` declarations.** Not `let` / `const`. Consistent with the rest of the codebase.
+- **No TypeScript, no transpilation.** What ships is what runs. Operators read the same source the runtime executes.
+- **No emojis in code or commits** unless explicitly requested. (User-facing docs like SECURITY.md and seeded wiki content are exceptions.)
+- **Top-of-file `require()`s.** Inline requires only for documented circular-dependency cases, with a comment explaining why.
+- **Use framework primitives over raw literals.** `C.TIME.minutes(5)` not `5 * 60 * 1000`. `C.BYTES.kib(64)` not `64 * 1024`. `timingSafeEqual(a, b)` for security-sensitive comparison, never `a === b`.
+
+### Ship complete, not incremental
+
+Every framework primitive is designed for completion from the start — not "minimum viable" with key features deferred to a follow-up. Before submitting a feature PR, list the full operator-facing scope in the issue's design discussion: what's in, what's out, why each "out" is a complete decision rather than a deferred bullet.
+
+If a slice genuinely shouldn't be in the first release (real ROI question, escape hatch exists, no operator demand), say so explicitly. "Defer with re-open conditions" is a complete answer; "future patch" is not.
+
+### Boot-time config validation
+
+Every primitive's `create()` validates its `opts` against an explicit allow-list using `b.validateOpts(opts, allowedKeys, "primitive.name")`. Typos like `cors({ allowedOrigins: [] })` (the API expects `origins`) throw at boot with the offending key plus the full allowed-keys list. Adding a new primitive? Add the validation in the same patch as the primitive itself.
+
+### Test coverage
+
+The test suite has four layers:
+
+- `test/layer-0-primitives/` — pure-function primitives, no DB / no network
+- `test/layer-1-state/` — primitives that touch the DB or vault
+- `test/layer-2-...` — middleware + composition
+- `test/layer-3-...` — end-to-end framework boot scenarios
+- `examples/wiki/test/e2e.js` — the wiki app exercised over real HTTP
+
+A new framework primitive lands with at least layer-0 tests. New middleware lands with layer-2 tests. New CLI subcommand lands with a `test/layer-0-primitives/cli-X.test.js` round-trip test (see `cli-vault.test.js`, `cli-backup.test.js`, `cli-api-key.test.js` for the shape).
+
+The smoke target is `OK — N checks passed` ending with a count higher than the previous release. New operator-facing routes / primitives add their own checks to `examples/wiki/test/e2e.js`.
+
+## The PR loop
+
+1. **Open an issue first** for non-trivial work — design discussion catches scope problems before code is written. Trivial fixes (typos, doc tweaks, single-line bug fixes) can skip the issue.
+2. **Branch off `main`.** Branch name doesn't matter; we squash on merge.
+3. **One concern per PR.** A new primitive + its tests + its wiki docs + the audit-namespace registration is one PR. A new primitive + an unrelated lint cleanup is two.
+4. **Fail-loud verification before push:**
+   - `node test/smoke.js` ends with `OK — N checks passed`
+   - `cd examples/wiki && rm -rf data data-e2e && node test/e2e.js` ends with `OK — N checks passed`
+   - `npx eslint@latest --max-warnings 0 .` exits 0
+   - `shellcheck $(git ls-files '*.sh')` exits 0 — every tracked shell script (vendor-update, docker-stack init scripts, etc.) parses clean. CI runs the same gate via `ludeeus/action-shellcheck`; surface lint findings before the push.
+   - **External-integration two-gate** — when the diff touches a primitive that talks to an external service (`lib/redis-client.js`, `lib/queue-redis.js`, `lib/mail.js`, `lib/network-dns.js`, `lib/object-store/*`, `lib/log-stream*.js`, `lib/external-db.js`, `lib/cluster-*.js`, `lib/mtls-ca.js`, `lib/ssrf-guard.js`, `lib/http-client.js`, `lib/ntp-check.js`, `lib/cache.js`, `lib/webhook.js`), bring the docker fixture stack up and run BOTH integration gates: `docker compose -f docker-compose.test.yml up -d --wait`, then `node scripts/test-integration.js` (per-primitive against real backends, must end with `[test-integration] OK`) AND `node scripts/test-wiki-integration.js` (wiki app exercising the same backends end-to-end through HTTP, must end with `[test-wiki-integration] OK`). The two gates catch bugs that mocks miss — fire-and-forget races, shutdown drains, TLS pinning, real DNS resolution, real protocol handshakes — and the wiki gate also validates the framework's primitives in a real-app context (middleware chain, request lifecycle, audit, observability). Both stay outside CI because they require docker, but operators must run them locally before any push that changes external-integration code.
+   - `node scripts/check-api-snapshot.js` exits 0 — guards the public API surface against accidental breaking changes. Intentional surface changes regenerate the baseline (`node scripts/refresh-api-snapshot.js`) and commit the updated `api-snapshot.json` alongside the change.
+   - `node examples/wiki/test/validate-primitive-sections.js` exits 0 — every primitive section in the wiki has the four pieces (heading + opts + prose + example). Runs automatically inside the wiki e2e step too, but the standalone run gives a fast local signal when only docs changed.
+5. **Commit message style:** lowercase imperative. The first line is a one-sentence summary; the body explains *why* and *what tradeoff*. See git log for examples.
+6. **Open the PR.** The `Lint summary` CI check is required to pass before merge — it aggregates ESLint + Hadolint + ShellCheck and posts a sticky comment on the PR with the results.
+7. **Review feedback** is usually one round. Reviewers focus on:
+   - Does this match the framework's existing patterns? (Audit-existing-code: did you sweep internals for replaceable patterns?)
+   - Is the failure mode loud at boot, not silent at request time?
+   - Is every operator-facing knob in the wiki / DEPLOY.md / Dockerfile env block?
+   - Does the patch ship complete, or does it leave a "future" bullet behind?
+
+## What to contribute
+
+Good contribution areas, ordered by current need:
+
+1. **Operator ergonomics** — wiki docs gaps, DEPLOY.md improvements, CLI verb usability, error messages that don't say what to do next.
+2. **Test coverage** — there are still framework primitives at lower test coverage than the rest. `git grep -L "test/layer-" lib/` reveals candidates.
+3. **Vendored-dep refreshes** — when an upstream library publishes a security or feature release, run `scripts/vendor-update.sh --check` then `vendor-update.sh <pkg>`. Patches refreshing vendored deps are always welcome.
+4. **Wiki content** — the wiki at blamejs.com is also the docs site. Filling in concern-group pages (or fixing existing ones) helps every operator.
+5. **CLI subcommands** — covered: migrate, seed, dev, api-snapshot, audit, vault, backup, api-key, mtls. Open: a `blamejs i18n missing-keys` reporter, a `blamejs scheduler list/trigger`, a `blamejs queue inspect` for operational debugging. See `lib/cli-helpers.js` for the headless-app + reporter pattern.
+
+What we don't want:
+
+- New runtime npm deps. Period.
+- TypeScript ports / transpiler builds.
+- Classical-only crypto fallbacks "for compatibility."
+- "Convenience" primitives that paper over a missing operator decision (e.g., a vault primitive that auto-generates a passphrase if none is set in production).
+
+## Maintainer responsibilities
+
+If you're being added as a maintainer, the additional commitments:
+
+- Triage incoming issues within 7 days
+- Respond to security reports per the SLA in [SECURITY.md](SECURITY.md)
+- Review PRs in your domain area within 14 days
+- Sign-off + tag releases via `node scripts/release.js` — eight idempotent subcommands (`prepare` → `smoke` → `commit` → `push` → `watch` → `merge` → `tag` → `publish`) plus `all` for a one-shot. See [examples/wiki/DEPLOY.md](examples/wiki/DEPLOY.md) → "Tag-driven releases" for the wiki-container side of the same flow.
+
+The maintainer list is in [MAINTAINERS.md](MAINTAINERS.md) (or `git log` if that file doesn't exist yet).
+
+## Getting help
+
+- **General questions:** GitHub Discussions on the repo
+- **Real-time:** the project doesn't run a Discord / Slack — async-by-design
+- **Security:** `security@blamejs.com` ([SECURITY.md](SECURITY.md))
+
+This document is governed by the [Code of Conduct](CODE_OF_CONDUCT.md). Be excellent.

package/lib/vendor/blamejs/GOVERNANCE.md

@@ -0,0 +1,201 @@
+# Governance
+
+blamejs is a server-side Node framework with a published LTS calendar
+and a documented threat model. This document captures how decisions
+get made, who makes them, and what happens if the maintainer becomes
+unavailable.
+
+It exists so an operator betting their stack on blamejs can answer
+three questions before they commit:
+
+1. Who decides what changes in the framework?
+2. What happens to the project if the maintainer disappears?
+3. How are operator-impacting changes (deprecations, removals,
+   security defaults) communicated?
+
+## Current governance model
+
+Solo maintainer, pre-1.0.
+
+- **Maintainer:** dotCooCoo (Robert Lee), via GitHub user [dotCooCoo](https://github.com/dotCooCoo).
+- **Organization:** github.com/blamejs.
+- **npm scope:** `@blamejs/*` (`@blamejs/core` is the framework; sibling
+  packages enumerated in [SECURITY.md → Namespace reservations](SECURITY.md#namespace-reservations)).
+
+The project transitions to a multi-maintainer model when an aligned
+co-maintainer with sustained core-area commit cadence joins. Until
+then, the maintainer is final on technical direction.
+
+## How decisions get made
+
+- **Technical direction.** Maintainer-final. Operator input arrives
+  via GitHub Issues + Discussions; the maintainer weighs it but the
+  final call rests with them. There is no formal vote.
+- **Security-vulnerability triage.** Per
+  [SECURITY.md](SECURITY.md#reporting-cves-in-vendored-dependencies)
+  — coordinated disclosure via GitHub Security Advisories, 7-day
+  fix target for High / Critical vendored CVEs, public advisory on
+  remediation.
+- **Operator-impacting changes.** Pre-1.0 the framework reserves the
+  right to break operator-facing surface in any minor version; major
+  versions ship deprecation warnings at least one minor before
+  removal (per project rule §6 in `CLAUDE.md`). Post-1.0 the same
+  contract applies across majors with a 24-month LTS window per
+  [LTS-CALENDAR.md](LTS-CALENDAR.md).
+- **Releases.** Patch (`0.0.x`) is the default; minor (`0.x.0`)
+  requires an explicit decision the maintainer documents in the
+  release notes; major (`x.0.0`) requires a deprecation cycle. The
+  full release workflow is documented in the project's local
+  contributor guide.
+- **Governance change process.** Edits to this file require an
+  operator-facing 30-day RFC period via GitHub Discussions. RFCs
+  open at the proposal stage and close with a maintainer decision
+  + rationale in the discussion thread.
+
+## Succession plan
+
+Bus-factor-1 is the largest non-technical risk the project carries.
+This section documents the recovery path so an operator depending on
+blamejs has a defensible plan if the maintainer becomes unavailable.
+
+### Designated successor
+
+**Status:** TBD with documented re-open trigger.
+
+A named successor requires:
+
+- An aligned contributor with sustained commit cadence to a core
+  area (auth / crypto / DB / mail-stack / release workflow).
+- Demonstrated familiarity with the architectural decisions
+  recorded in `docs/adr/`, `ARCHITECTURE.md`, and
+  `memory/specs/` (the latter is maintainer-local but the public
+  ADRs + ARCHITECTURE.md should let a successor reconstruct the
+  decision context).
+- A documented commitment to the project's stated discipline:
+  zero npm runtime deps, PQC-first defaults, security-on-by-default,
+  no AI/Anthropic attribution in shipped artifacts, no internal-process
+  narrative in operator-facing surface.
+
+The maintainer reviews successor candidacy whenever a contributor
+crosses the sustained-core-area-commit threshold. Until a successor
+is named, sections below describe the fallback path.
+
+### Repository ownership
+
+GitHub Organization (`blamejs`) is currently single-owner. The
+maintainer commits to adding a second organization owner within
+30 days of naming a designated successor.
+
+Until a second owner is named, the maintainer-incapacitation path
+goes through GitHub Support's account-recovery flow (DNS + 2FA
+recovery codes; see below).
+
+### npm publish credentials
+
+The npm publishing identity owns the `@blamejs` scope. Publish
+authority for releases lives in:
+
+1. **Primary:** OIDC trusted-publisher binding (GitHub Actions
+   environment-scoped, npm `--provenance` flow). Already in place.
+2. **Backup automation token:** 2FA-protected, recovery codes
+   stored offline. The token is scoped to publish-only on the
+   `@blamejs` scope.
+
+If the maintainer becomes incapacitated, recovery is via npm
+Support's account-recovery flow keyed off the registered domain
+(blamejs.com) and 2FA recovery codes.
+
+### SSH signing key (commit + tag signatures)
+
+Every release commit and tag is SSH-signed. The public key
+fingerprint is published in
+[SECURITY.md → Verifying release authenticity](SECURITY.md#verifying-release-authenticity).
+
+**Rotation procedure** (planned; runs when needed):
+
+1. Generate a new keypair.
+2. Sign a key-rotation announcement with the **old** key (during
+   an overlap window where both keys are valid).
+3. Update `~/.ssh/allowed_signers` (operator-side verification
+   files) + SECURITY.md fingerprint.
+4. Push the rotation announcement to LTS-CALENDAR.md so operators
+   running automated tag-signature verification can update their
+   pinned fingerprint.
+5. Revoke the old key 30 days after the announcement.
+
+### Sigstore / cosign keyless
+
+Identity-based; rotation is automatic when GitHub Organization
+ownership rotates. No standalone key material to manage.
+
+### Critical knowledge
+
+Architectural decisions land in **public, repo-resident artifacts**:
+
+- `docs/adr/` — Architecture Decision Records (rationale captured
+  at decision-time, not reconstructed after the fact).
+- `ARCHITECTURE.md` — high-level system shape.
+- `CHANGELOG.md` (derived from `release-notes/*.json`) —
+  operator-facing surface evolution.
+
+Maintainer-local notes under `memory/specs/` are NOT
+operator-facing and are not durable — a successor inheriting the
+project relies on the public artifacts above plus the source code
+itself.
+
+## Key-loss recovery
+
+| Asset | Recovery path |
+|---|---|
+| npm publish | npm Support account-recovery flow (registered domain + 2FA recovery codes); backup automation token sealed offline. |
+| GitHub org ownership | GitHub Support account-recovery flow with 2FA recovery codes. |
+| SSH signing key | Key-rotation procedure above; 30-day operator-notification window via LTS-CALENDAR.md. |
+| Sigstore / cosign | Identity-based — rotates with GH org ownership. |
+| Domain (blamejs.com) | Registrar account-recovery flow; DNS held with 2FA + recovery email. |
+
+## Dependent-notification protocol
+
+If the maintainer becomes unavailable, the project enters a
+documented recovery process rather than silent decay.
+
+- **Contact channel:** `security@blamejs.com` per SECURITY.md.
+  The mailbox is dual-controlled at the email + DNS level (DNS
+  held by the registrar with 2FA + recovery email; mail routed
+  through the registrar's MX records).
+- **Escalation trigger:** if no maintainer activity for 30 days
+  **and** no scheduled hiatus pre-announced in LTS-CALENDAR.md,
+  the designated-successor process activates. If no successor is
+  named, the project enters maintenance-hibernation status with
+  a public announcement on the GitHub README.
+- **Public announcement format:** README banner + a pinned issue
+  + a CHANGELOG entry documenting the status change. Operators
+  on the npm package see no surface change (the published
+  versions stay reachable); operators bumping a pinned dependency
+  see the hibernation banner before they upgrade.
+
+## Open: items the maintainer commits to address
+
+These are documented gaps in the current governance posture. The
+re-open trigger for each is operator-visible so the operator can
+evaluate the project's posture against their own risk tolerance.
+
+1. **Named successor.** TBD; re-opens when a contributor crosses
+   the sustained-core-area-commit threshold described above.
+2. **Second GitHub org owner.** Adds within 30 days of naming a
+   successor (no separate trigger; tracks succession).
+3. **OpenSSF Best Practices Badge — Silver tier.** Structurally
+   addressable once the multi-maintainer model is live. Gold tier
+   requires several additional discipline items beyond governance.
+4. **`docs/adr/` first ADRs.** The directory exists in spirit
+   (architectural decisions are recorded in commits, release
+   notes, and `memory/specs/`); promoting the high-value
+   decisions to repo-resident ADRs is a backlog item the
+   maintainer tracks.
+
+## References
+
+- OpenSSF Best Practices Badge governance criterion.
+- bus-factor risk class (opensauced.pizza research on solo-maintainer
+  popular GH projects).
+- npm Support account-recovery flow.
+- GitHub Support account-recovery flow.

package/lib/vendor/blamejs/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for describing the origin of the Work and
+      reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 blamejs contributors
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+   implied. See the License for the specific language governing
+   permissions and limitations under the License.