Jern Cloud docs

Update the dependencies every Monday.

The first thing most teams schedule. The baseline lets the agent touch the dependency files and run the tests, the schedule asks once a week, and the pull request lists what changed. The public demo has no dependencies, so this recipe shows the setup and not a run.

The policy

A baseline for a Python project that allows edits to the dependency files beside the source, and names the test command so every edit is checked:

{
  "policy": {
    "edits_within": ["src/", "tests/", "requirements.txt", "requirements-dev.txt"],
    "protected_paths": [".jern/", ".github/"],
    "max_files_edited": 3,
    "max_lines_changed": 60,
    "shell_allow": ["python3 -m pytest -q"]
  },
  "environment": {
    "network_allow": ["pypi.org"]
  },
  "test_command": "python3 -m pytest -q"
}

Setup runs before the agent starts and installs from the lockfile with the network open to the package index; during the run, the agent can look a package up through package_info, which asks the registry for the latest version and nothing else, and read pypi.org pages if the baseline allows the host. It cannot install anything itself: the setup phase does that on the next attempt, from the lockfile the pull request changes.

The schedule

When	`0 9 * * 1` in your zone: Mondays at 09:00.
Message	Update each dependency in requirements.txt to its latest version that keeps the tests passing. Check the current versions with package_info before changing anything. Open a pull request whose description lists every change as "name: old → new" and links the changelog of any major version bump.
Cap	Lower than the trigger cap, since the task is bounded: 500,000 tokens is plenty.

What to expect

One pull request every Monday, or none when nothing changed, with the receipt check stating the files touched against the limit of three, the registry lookups, and the spend. A dependency whose new version breaks a test is left where it was, with the failure quoted in the pull request. The next Monday's run starts from the merged state; a pull request left open is not touched again, since each run opens its own session.

Why not a bot that does this already

Dependency bots open one pull request per package and cannot run your tests before deciding. A scheduled session can be asked for anything in the same breath: update, run the suite, fix a deprecation the update surfaces, and explain the change, under a blast radius and with a receipt. The price is a model call, capped.

Try it on your repository

Add the dependency files to edits_within in the baseline and merge it.
Turn triggers on, then add the schedule on the repository's page.
After the first run, read the receipt check before the diff. It says what the agent looked up and touched.