If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/alibaba/jvm-sandbox shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 10 active contributors
• LGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 62% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live alibaba/jvm-sandbox repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/alibaba/jvm-sandbox.

What it runs against: a local clone of alibaba/jvm-sandbox — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in alibaba/jvm-sandbox | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 184 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of alibaba/jvm-sandbox. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/alibaba/jvm-sandbox.git
#   cd jvm-sandbox
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of alibaba/jvm-sandbox and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "alibaba/jvm-sandbox(\\.git)?\\b" \\
  && ok "origin remote is alibaba/jvm-sandbox" \\
  || miss "origin remote is not alibaba/jvm-sandbox (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/AgentLauncher.java" \\
  && ok "sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/AgentLauncher.java" \\
  || miss "missing critical file: sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/AgentLauncher.java"
test -f "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/EventListener.java" \\
  && ok "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/EventListener.java" \\
  || miss "missing critical file: sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/EventListener.java"
test -f "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java" \\
  && ok "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java" \\
  || miss "missing critical file: sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java"
test -f "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java" \\
  && ok "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java" \\
  || miss "missing critical file: sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java"
test -f "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/Event.java" \\
  && ok "sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/Event.java" \\
  || miss "missing critical file: sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/Event.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 184 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~154d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/alibaba/jvm-sandbox"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

JVM-SANDBOX is a real-time non-invasive AOP framework that dynamically intercepts and enhances Java methods at runtime without restarting the target JVM or modifying its source code. It uses Instrumentation-based bytecode weaving to intercept method calls at BEFORE/RETURN/THROWS lifecycle points, enabling on-the-fly method parameter inspection, return value manipulation, and execution flow control—all while maintaining strict class isolation via custom SandboxClassLoader and ModuleJarClassLoader. Multi-module Maven monorepo: sandbox-agent/ contains AgentLauncher (JVM attach entry point) and SandboxClassLoader (custom CL); sandbox-api/ defines modular contracts (ModuleLifecycle, ProcessController, event classes: BeforeEvent, CallBeforeEvent, CallReturnEvent, CallThrowsEvent, ImmediatelyReturnEvent); bin/ holds shell deployment scripts (sandbox.sh, sandbox.properties config, logback.xml logging); doc/ has architecture and user guides.

DevOps engineers and platform teams debugging production issues without restarting services; performance engineers implementing dynamic tracing and fault injection; monitoring platform builders needing real-time method-level visibility; developers of tools like call-chain recorders, dynamic logging systems, and exception simulators who want a shared AOP substrate.

Production-ready. Alibaba's open-source project with Travis CI integration, multi-JDK support (JDK 6–11), version 1.4.0 released, and comprehensive Chinese/English documentation (doc/JVM-SANDBOX-USER-GUIDE-.md, doc/JVM-SANDBOX-DEVELOPER-GUIDE-.md). Last visible state shows active maintenance and stability focus; CI badge present indicates ongoing build verification.

Low risk for production use at Alibaba scale, but single-maintainer core (luanjia, vlinux) means slower response to critical issues. The design deliberately breaks Java's ClassLoader parent-delegation contract—requires deep JVM internals knowledge to troubleshoot class-loading edge cases. GPLv3 license may conflict with closed-source derivatives; verify licensing before bundling.

Repository structure and documentation are mature; no specific active PR/issue data visible from provided snapshot. Historical development focused on class isolation, event model refinement, and multi-JDK compatibility. Current state appears stable maintenance rather than active feature development.

Clone and build with Maven: git clone https://github.com/alibaba/jvm-sandbox.git && cd jvm-sandbox && mvn clean install. Deployment uses shell scripts: bin/sandbox.sh install <target-java-pid> attaches the agent; see bin/sandbox-release.sh for packaging. Review doc/JVM-SANDBOX-USER-GUIDE-English.md for configuration (bin/sandbox.properties) and module development.

Daily commands: After mvn clean install, use bin/sandbox.sh install <pid> to attach to running JVM, or bin/sandbox.sh start with bin/sandbox.properties configuration. bin/sandbox-packages.sh bundles distribution; bin/set-version.sh manages version bumps. No dev server—this is an agent, not a service.

• sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/AgentLauncher.java — JVM agent entry point that bootstraps the sandbox framework into a running JVM process via instrumentation.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/EventListener.java — Core listener interface that all sandbox modules implement to intercept and handle instrumented method events.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java — Extended listener pattern for advice-based AOP that modules use to react to before/after/throw events.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java — Primary API for modules to register method watchers and define event filtering and transformation logic.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/Event.java — Base event hierarchy that represents runtime method invocation events with context and state.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/ModuleLifecycle.java — Module lifecycle interface defining onLoad/onUnload hooks for initialization and cleanup during module deployment.
• sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/filter/Filter.java — Matching filter abstraction used to selectively instrument classes and methods by name, modifier, and annotation.

Add a New Sandbox Module

1. Create a new Maven module directory under the project root with a pom.xml defining dependencies on sandbox-api. (pom.xml)
2. Implement the ModuleLifecycle interface (or extend ModuleLifecycleAdapter) to define onLoad and onUnload hooks. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/ModuleLifecycleAdapter.java)
3. Inject ModuleEventWatcher resource and use EventWatchBuilder to register event listeners for target methods. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java)
4. Implement EventListener or extend AdviceListener to handle BeforeEvent, ReturnEvent, and ThrowsEvent. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java)
5. Use Filter and NameRegexFilter to define which classes and methods to instrument. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/filter/NameRegexFilter.java)
6. Package the module JAR and deploy to the sandbox container via CLI or HTTP API. (bin/sandbox.sh)

Add Method Invocation Tracking

1. In your module's onLoad, obtain the injected ModuleEventWatcher resource. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java)
2. Use EventWatchBuilder to define a filter matching your target class and method using regex or class matchers. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/EventWatchBuilder.java)
3. Create an AdviceListener that overrides before(), after(), and afterThrowing() to capture invocation data. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/AdviceListener.java)
4. Call ModuleEventWatcher.watch() with your filter and listener to register the watch. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/resource/ModuleEventWatcher.java)
5. Access method parameters, return value, and exception via the Advice context object. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/Advice.java)

Implement Dynamic Return Value Modification

1. In your AdviceListener's before() or after() method, check conditions using the Advice context. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/ext/Advice.java)
2. Create an ImmediatelyReturnEvent to override the method's return value and bypass remaining code. (sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/ImmediatelyReturnEvent.java)

JVM version lock: Must match target app's JDK version (6–11 supported); mixing versions causes agent load failure. Parent-delegation breach: Custom SandboxClassLoader deliberately violates ClassLoader contract—edge case: if target app or other agents also use custom CL, initialization order matters (sandbox should load first via JAVA_TOOL_OPTIONS or javaagent=-javaagent:... positional argument). Module isolation cost: Each module jar gets its own ModuleJarClassLoader—if modules share large dependencies, memory footprint multiplies; no deduplication mechanism. No hot-reload safety net: Unloading a module leaves bytecode patches in place; if module had bugs, reloading may not fully reset (JDK JVMTI constraints). Config location: bin/sandbox.properties must exist in agent working directory at runtime; relative paths assumed. Instrumentation scope: Cannot instrument bootstrap classes without @IncludeBootstrap annotation; default excludes java.* and sun.* to avoid JVM crashes.

• Java Instrumentation & JVMTI — JVM-SANDBOX's entire runtime interception capability depends on the Instrumentation API (java.lang.instrument) and ClassFileTransformer; understanding premain/agentmain hooks and JVMTI-level class redefinition constraints (no field/method addition) is mandatory to understand why sandbox's bytecode weaving must be non-invasive.
• ClassLoader Hierarchy & Parent-Delegation Model — SandboxClassLoader deliberately breaks the standard parent-delegation contract to achieve class isolation; learning why parent-delegation exists and how sandbox circumvents it is key to understanding the isolation guarantees and potential pitfalls.
• Bytecode Generation & ASM — Sandbox's weaving logic injects BEFORE/RETURN/THROWS event dispatch code into target methods at the bytecode level; understanding bytecode structure (method frames, exception handlers, instruction sequences) and ASM's visitor pattern is essential for modifying the weaver or debugging instrumentation failures.
• Event-Driven Interception (BEFORE/RETURN/THROWS) — Sandbox's entire execution model (ProcessController.forceReturn, exception manipulation, parameter modification) is built on decomposing method calls into three lifecycle events; this is the mental model needed to write correct interceptor logic.
• Module Class Isolation (ModuleJarClassLoader) — Each sandbox module loads in its own ClassLoader to prevent dependency conflicts between modules and with the target app; understanding this multi-level isolation (SandboxClassLoader > ModuleJarClassLoader per module) is critical to debugging class-not-found or version-mismatch issues.
• Non-Invasive Runtime Bytecode Patching — Unlike traditional AOP (Spring, cglib) that require source-level annotations or proxy objects, sandbox patches bytecode at runtime without modifying the original class structure; this requires deep knowledge of JDK's JVMTI constraints (no field/method addition) and creative bytecode reuse to achieve true non-invasiveness.
• Dynamic Agent Attachment (Attach API) — Sandbox can attach to a running JVM via VirtualMachine.attach(pid) without restart; understanding the attach protocol, socket communication between agent JVM and target JVM, and signal handling is necessary for troubleshooting deployment failures or implementing custom attach mechanisms.

• btraceio/btrace — Direct predecessor and inspiration—BTrace is a mature JVM tracing tool; JVM-SANDBOX explicitly positions itself as a more modular, non-invasive alternative with better fault isolation
• alibaba/arthas — Companion Alibaba tool—Arthas is a Java diagnostic CLI that works with JVM-SANDBOX for runtime troubleshooting, offering REPL-based method interception on top of sandbox's AOP substrate
• openjdk/jdk — Dependency—JVM-SANDBOX relies on java.lang.instrument (Instrumentation API) and ClassFileTransformer; understanding OpenJDK's JVMTI is essential for contributing to core weaving logic
• spring-projects/spring-framework — Ecosystem integration point—modules often intercept Spring Bean lifecycle; understanding Spring's AOP (ProxyFactoryBean, @Aspect) helps explain sandbox's advantages (non-invasive vs. Spring's container coupling)
• alibaba/transmittable-thread-local — Complementary Alibaba library—often used inside sandbox modules to propagate trace context across threads without polluting the target app's thread-local state

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for sandbox-api filter implementations

The sandbox-api module contains multiple filter classes (Filter.java, NameRegexFilter.java, ExtFilter.java, OrGroupFilter.java, AccessFlags.java) but there's no visible test directory structure for sandbox-api/src/test. These filters are critical for AOP matching logic and lack test coverage. Adding unit tests would improve code reliability and make it easier for contributors to understand filter behavior.

• [ ] Create sandbox-api/src/test/java/com/alibaba/jvm/sandbox/api/filter/ directory structure
• [ ] Add unit tests for NameRegexFilter.java covering regex matching edge cases (special chars, anchors, quantifiers)
• [ ] Add unit tests for OrGroupFilter.java testing filter combination logic
• [ ] Add unit tests for AccessFlags.java verifying flag matching for public/private/static methods
• [ ] Add integration tests for ExtFilter.java and ExtFilterImplByV140.java
• [ ] Update pom.xml with junit/testng dependencies if missing

Add GitHub Actions CI workflow to replace Travis CI

The repo uses .travis.yml for CI/CD, but Travis CI has deprecated free tier support for open source projects. GitHub Actions is native to GitHub and more cost-effective. This would modernize the CI setup and ensure builds continue to run reliably. The file structure shows active development but relies on outdated CI infrastructure.

• [ ] Create .github/workflows/build.yml with Maven build steps for Java projects
• [ ] Add separate workflow for running tests with codecov integration
• [ ] Add workflow for building and testing against multiple Java versions (8, 11, 17)
• [ ] Migrate badge URLs in README.md from Travis CI to GitHub Actions
• [ ] Archive or remove .travis.yml after migration verification
• [ ] Document the CI setup in CONTRIBUTING.md

Add documentation for event system and create example module guide

The sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/ directory contains 9 event types (BeforeEvent, ReturnEvent, ThrowsEvent, LineEvent, etc.) but the developer guide lacks detailed explanation of which events are appropriate for different AOP scenarios. New contributors struggle to understand when to use CallBeforeEvent vs InvokeEvent vs LineEvent. A comprehensive guide with examples would reduce barrier to entry.

• [ ] Create doc/EVENT-TYPES-GUIDE.md documenting each event class in sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/event/
• [ ] Add diagrams showing event lifecycle (BeforeEvent → InvokeEvent → CallBeforeEvent → CallReturnEvent → ReturnEvent)
• [ ] Create a working example module in doc/examples/ showing how to use each event type for common scenarios (method tracing, exception handling, line-level debugging)
• [ ] Document ImmediatelyReturnEvent and ImmediatelyThrowsEvent use cases in ProcessController.java context
• [ ] Link the new guide from existing doc/JVM-SANDBOX-DEVELOPER-GUIDE-English.md and Chinese version

• Add unit test coverage for SandboxClassLoader edge cases (concurrent module loading, missing jar dependencies). Currently no test files visible in sandbox-agent/src/test/; start with a test that verifies class isolation when two modules reference the same dependency class.: Medium: Core isolation logic is untested; risks undiscovered bugs in load order or resource cleanup
• Document the @IncludeBootstrap, @IncludeSubClasses, @Stealth annotations with runnable examples in doc/. Currently only stub classes exist in sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/annotation/; add a markdown file explaining when/why to use each.: Small: Module developers have no clear guidance on annotation semantics; reduces barrier to writing correct interceptors
• Add module unload validation tests. Verify that after ProcessController.forceReturn() is called and module is unloaded, subsequent calls to that method execute original bytecode unmodified. File location: new test under sandbox-api/src/test/ or sandbox-core (if it exists).: Medium: Critical correctness claim—no invasiveness after unload—is not systematically verified; edge case: nested calls during unload may leak modified behavior

• High · Incomplete POM.xml - Potential Unvetted Dependencies — pom.xml. The pom.xml file provided is truncated at the plugin section for Sonatype profile. This makes it impossible to fully audit all declared dependencies. There may be outdated or vulnerable transitive dependencies that are not visible in the current analysis. Fix: Provide the complete pom.xml file. Run 'mvn dependency:tree' and 'mvn dependency:check-updates' to identify outdated or vulnerable dependencies. Consider using OWASP Dependency-Check Maven plugin to scan for known vulnerabilities.
• High · JVM Agent Code Execution Risk — sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/. The sandbox-agent module (AgentLauncher.java, SandboxClassLoader.java) implements a JVM agent that performs runtime bytecode instrumentation. This is a high-privilege operation that could be exploited if the agent loading mechanism is not properly secured. Agents can bypass security managers and execute arbitrary code with JVM privileges. Fix: Implement strict validation of agent configuration sources. Use code signing for agent JARs. Restrict agent loading to trusted sources only. Implement comprehensive audit logging for all instrumentation operations. Consider implementing a whitelist of allowed instrumentable classes.
• High · Dynamic Class Loading via SandboxClassLoader — sandbox-agent/src/main/java/com/alibaba/jvm/sandbox/agent/SandboxClassLoader.java. The SandboxClassLoader performs dynamic class loading which could be exploited to load malicious classes if not properly restricted. Custom classloaders increase the attack surface for classloader manipulation attacks. Fix: Implement strict class loading validation. Verify all loaded classes are from trusted sources (jar signatures). Implement a class whitelist/blacklist mechanism. Add security manager checks for classloader operations. Log all class loading attempts.
• High · WebSocket Implementation - Potential Attack Vector — sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/http/websocket/. The codebase includes WebSocket support (websocket/ directory) which is exposed via HTTP. WebSockets can be vulnerable to: CSWF attacks, message injection, improper authentication, and lack of encryption if not properly implemented. Fix: Ensure WebSocket endpoints validate the Origin header. Implement proper authentication and authorization for WebSocket connections. Use WSS (WebSocket Secure) over TLS. Validate and sanitize all WebSocket messages. Implement rate limiting and connection limits. Add CSRF token validation.
• High · HTTP API Exposure Without Visible Security Controls — sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/http/Http.java. The Http.java and HTTP-related classes suggest the framework exposes an HTTP API. Based on the file structure, there's no visible authentication mechanism in the provided files (no OAuth, JWT, API key validation visible). Fix: Implement strong authentication (OAuth 2.0, JWT, or mutual TLS). Require HTTPS/TLS for all HTTP endpoints. Implement rate limiting and DDoS protection. Add request validation and sanitization. Implement CORS policies properly. Add security headers (CSP, X-Frame-Options, etc.). Document all exposed endpoints.
• Medium · EventListener Processing - Potential Code Injection — sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/listener/EventListener.java and related listener classes. The EventListener framework accepts event handling code that processes runtime information. If event handlers process untrusted input (class names, method names, arguments), this could lead to code injection or expression language injection attacks. Fix: Implement strict input validation for all event listener parameters. Use allowlists for acceptable values. Avoid dynamic code generation or expression evaluation on user input. Implement sandboxing for event handler execution. Log all event processing activities.
• Medium · Filter Implementation - Regex DoS Risk — sandbox-api/src/main/java/com/alibaba/jvm/sandbox/api/filter/NameRegexFilter.java. The codebase includes NameRegexFilter and pattern matching capabilities (NameRegexFilter.java, ExtFilter.java). Poorly constructed regex patterns could be vulnerable to ReDoS (Regular Expression Denial of Service) attacks. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.