-
Notifications
You must be signed in to change notification settings - Fork 0
feat(policy)!: a refusal is typed, overrides are issued, and the shell tier retires behind the migration gate #712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
wenzowski
merged 38 commits into
main
from
claude/cloud-1050-1059-implementation-b0xe2s
Aug 27, 2026
Merged
Changes from all commits
Commits
Show all changes
38 commits
Select commit
Hold shift + click to select a range
80f6d77
feat(policy): a migration that touches a shell rule retires it
wenzowski 7f35fa2
style(policy): the two lints the shell-retirement row landed with
wenzowski bbd4a0c
feat(transcript): the host's rule-injection event, and the census ove…
wenzowski f2153a4
feat(policy)!: a refusal is {rule, verdict, subjects}, and there is n…
wenzowski 66a5e5c
feat(receipt)!: an override becomes an issued record, not a variable …
wenzowski 0f429c6
feat(policy)!: prose-only-check becomes a rego row, and check learns …
wenzowski 958c28c
refactor(git): base_delta classifies by blob id, and reads only what …
wenzowski af3605b
feat(recorder): a record's shape is the consumer's, and its column ma…
wenzowski b0dc0d4
feat(recorder)!: the board-write record becomes a declaration, and th…
wenzowski af4fa64
feat(policy): the Stop moment reaches a module, so its rules can be Rego
wenzowski 835b680
feat(policy): the output-posture tell becomes a module, the first of …
wenzowski 474a11f
feat(cli)!: an admission is spent, which is what makes the bare varia…
wenzowski 523b721
feat(facts): the recorder's record becomes a tree fact, so a gate can…
wenzowski ebab84d
feat(policy)!: CLOUD-514's two refusals become a module, and the shel…
wenzowski adcb925
fix(hook): the end-of-turn module was a dead gate, and this is what p…
wenzowski 97ceeac
feat(hook)!: the end of turn becomes the engine's, and stop-guard.sh …
wenzowski bc2fbb0
fix(hook): the transcript symlink loses its only writer when stop-gua…
wenzowski 41a436b
fix(rebase): three line ceilings the merge crossed, resolved along ex…
wenzowski 840067f
chore: regenerate completions and the policy man page for both merged…
wenzowski 74f7692
fix(policy)!: two modules main grew during the rebase move to the typ…
wenzowski 3736e6b
refactor(exec): the two new spawns move to the placed adapter
wenzowski 0ad14c7
feat(policy)!: the review-answered suite retires, and the edit arm le…
wenzowski a45f6f2
chore(bench): regenerate the suite cost table for 154 suites
wenzowski e39f197
fix(policy): the retirement ledger's own arms, and the module the lay…
wenzowski 31cae81
perf(policy)!: a module's own test rules stop riding the hot path
wenzowski baa5dc6
refactor(policy): the module read splits out, at the seam the I/O alr…
wenzowski 6839619
fix(exec): a shebang program reaches the ladder, which is what Window…
wenzowski d9b36ab
fix(tests): the Windows shebang the ladder can read, and the third pr…
wenzowski d77371a
build(deps): gix 0.87, because every version of bisync was yanked und…
wenzowski 92725b2
feat(semver): the compatibility gate becomes an adapter, with a basel…
wenzowski 550573b
feat(cli)!: `batten semver check`, and the gate answers again
wenzowski fba3f78
feat(policy)!: semver.sh retires, and the gate it leaves behind reads…
wenzowski bc5e9a3
fix(semver): the baseline tree is materialized through gix, not a git…
wenzowski 0471b9c
fix(semver): the toolchain read moves into the adapter `spawn-adapter…
wenzowski 00a3abd
chore(bench): regenerate the suite cost corpus over the 153 suites th…
wenzowski b05f9bf
fix(semver): five censuses name the new verb, and every one of them f…
wenzowski c6d171e
fix(tests): the shell-stub cases are unix-only, which is what Windows…
wenzowski b0440e6
ci(workflows): reclaim runner disk before the build, and record what …
wenzowski File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
Repository: button-inc/batten
Length of output: 11628
🌐 Web query:
GitHub Actions GITHUB_STEP_SUMMARY file path runner temporary directory documentation bash -e run step💡 Result:
In GitHub Actions, GITHUB_STEP_SUMMARY is an environment variable that holds the path to a temporary file on the runner [1][2]. This file is used to store custom Markdown content that GitHub displays on the workflow run summary page [2][3]. Key details regarding GITHUB_STEP_SUMMARY: File Path and Location: The file path contained in the GITHUB_STEP_SUMMARY environment variable is generated by the runner and is unique to each individual step within a job [1][2]. It typically resides within the runner's temporary directory structure, following a pattern like /home/runner/_layout/_work/_temp/runner_file_commands/step_summary[unique_id] (though the exact path is subject to internal runner implementation and should be accessed via the environment variable rather than hardcoded) [1][4]. Usage in Bash: To add content to the job summary, you append your Markdown-formatted text to the file specified by the variable [2][5]. In a standard bash run step, this is commonly achieved using the append redirection operator (>>): echo "### My Custom Summary" >> $GITHUB_STEP_SUMMARY Best Practices: - Content Format: Job summaries support GitHub-flavored Markdown [2][6]. - Multi-step Aggregation: Because the file is unique to each step, you can append content across multiple steps in a job to build a comprehensive summary [7]. - Character Encoding: It is recommended to use UTF-8 encoding when writing to the file [6]. - Environment check: If you are writing a custom action that might run locally (outside of GitHub Actions), ensure you check if GITHUB_STEP_SUMMARY is present in the environment variables before attempting to write to it, as the variable will only exist within the GitHub Actions runner environment [5]. While RUNNER_TEMP also provides a path to a temporary directory on the runner (often used for ephemeral files that are cleared between jobs), GITHUB_STEP_SUMMARY is specifically reserved for the job summary file mechanism managed by the runner [8].
Citations:
🌐 Web query:
GitHub-hosted Ubuntu runner filesystem /usr/share/dotnet GITHUB_STEP_SUMMARY same filesystem💡 Result:
On GitHub-hosted Ubuntu runners, /usr/share/dotnet and the file referenced by GITHUB_STEP_SUMMARY are not necessarily on the same filesystem. 1. /usr/share/dotnet is the default directory where.NET is installed on GitHub-hosted Linux runners [1]. It is part of the base runner image, which is mounted as the root partition (/) of the runner environment [2][3]. 2. GITHUB_STEP_SUMMARY is an environment variable that points to a temporary file path on the runner [4][5]. This file is created dynamically for each step in a workflow [4][6]. While its exact location can vary, it resides within the runner's internal temporary directory structure, typically located under /home/runner/_layout/_work/_temp/_runner_file_commands/ [4][5]. Because the root partition (/) and the /home partition are often separate filesystems on many Linux distributions (and cloud runner configurations), these two paths frequently reside on different filesystems. Even if they are on the same physical disk, they are distinct mount points. You should not assume they share the same filesystem, as file operations requiring a common mount point (such as hard links or certain atomic moves) may fail across these paths [4][7].
Citations:
🌐 Web query:
site:github.com/actions/runner GITHUB_STEP_SUMMARY step_summary _runner_file_commands RUNNER_TEMP source💡 Result:
In GitHub Actions, GITHUB_STEP_SUMMARY, _runner_file_commands, and RUNNER_TEMP are interrelated components of the runner's architecture for handling task-specific data and workflow commands [1][2]. RUNNER_TEMP RUNNER_TEMP is an environment variable that points to the temporary directory used by the GitHub Actions runner for a specific job [3][2]. It is used to store temporary files created by actions or workflow steps [3]. In jobs running inside containers, the runner automatically maps and translates the host's temporary directory to a path accessible within the container (typically /w/_temp) to ensure consistency [4][5][2]. _runner_file_commands _runner_file_commands is a subdirectory located within the directory defined by RUNNER_TEMP [1][2]. It acts as a central repository for "file commands"—specialized files created by the runner that allow actions to communicate state changes or metadata back to the workflow runner (e.g., setting environment variables, output parameters, or step summaries) [1][2]. GITHUB_STEP_SUMMARY GITHUB_STEP_SUMMARY is an environment variable that provides the file path to a specific file within the _runner_file_commands directory [6][2]. When an action writes markdown content to this path, the runner uploads that content as a "Job Summary" associated with that step [6][7]. The content is isolated between steps and is subject to size limitations (e.g., 1MiB per step) [8][9]. Relationship Summary When a step executes, the runner assigns it a unique file path for operations like saving summaries or outputs, which are then placed inside the _runner_file_commands directory [6][1][2]. GITHUB_STEP_SUMMARY holds the specific path for the current step's summary file, while RUNNER_TEMP provides the root location for all such temporary and command-related storage [6][3][2].
Citations:
🌐 Web query:
site:github.com/actions/runner-images Ubuntu github hosted runner mount points /home/runner _work /usr/share💡 Result:
On Ubuntu GitHub-hosted runners, the directories /home/runner/_work and /usr/share serve specific roles in the runner's file system structure [1][2][3]. /home/runner/_work This directory acts as the primary workspace for GitHub Actions jobs [1]. - Purpose: It serves as the root location where the runner clones your repository and executes your workflow steps [1]. - Structure: When running jobs within a Docker container, the runner explicitly mounts /home/runner/work from the host machine to /w inside the container to provide access to your repository code, actions, and temporary files [1]. - Organization: Subdirectories such as _temp and _actions are typically located within this work directory to manage temporary data and downloaded action code during the job execution [1]. /usr/share This is a standard Linux directory used for storing architecture-independent data, such as documentation, configuration files, and application-specific data [2][3]. - Usage in GitHub Actions: In the context of GitHub-hosted runners, it contains pre-installed software dependencies, language runtimes, and drivers [2][3]. For example, paths like /usr/share/miniconda or various WebDriver binaries are often configured as environment variables pointing into this directory [2][3]. - Permissions: While typically owned by the root user in standard Linux distributions, there have been historical instances where runner image updates have unintentionally changed the ownership of /usr/share (and sometimes /etc or /opt) to the runner user to facilitate easier installation or configuration by pre-installed tools [4][5]. Key Considerations: - User Context: The GitHub Actions runner agent executes as the runner user [1]. While this user generally has permission to access the workspace, they rely on the specific permissions set on the host image for other directories like /usr/share [1][5]. - Reliability: You should avoid relying on the internal file structure or permissions of system directories like /usr/share, as these are subject to change based on the runner image version and internal configuration updates [4][5]. Always reference the official environment variables (e.g., GITHUB_WORKSPACE) provided by GitHub Actions to locate your project files rather than hard-coding paths to /home/runner/_work [1][6].
Citations:
🌐 Web query:
GitHub Actions hosted runner RUNNER_TEMP /home/runner/work/_temp filesystem mount Ubuntu documentation💡 Result:
On GitHub Actions Ubuntu-hosted runners, the
RUNNER_TEMPenvironment variable points to the path/home/runner/work/_temp[1][2][3]. This directory is located within the same filesystem as the repository workspace (/home/runner/work/) [4][1]. Key technical characteristics include: Filesystem Mounting: The directory is part of the standard workspace volume [4]. It is not a separate mount point (like atmpfs) by default [5]. Because it shares the same filesystem as the repository checkout, operations like moving files between the workspace andRUNNER_TEMPare typically atomic and avoid cross-device link errors (e.g.,EXDEV) [5]. Lifecycle and Scope: The directory is scoped to a specific job [2]. It is automatically cleared at the beginning and end of each job [6][2]. If files persist, it is usually because the runner's user account lacks the necessary permissions to delete them [6][7]. Container Actions: In containerized actions, the handling of this path is specialized. Historically,RUNNER_TEMPwas not automatically mounted inside Docker-based actions, leading to visibility issues where the container could not access files placed there by previous job steps [8]. While newer runner versions and specific configurations may map this path (e.g., mapping to/github/runner_tempor ensuring it remains part of the shared workspace volume), users should be aware that files in/home/runner/work/_tempare inherently bound to the runner host's filesystem [9][8][4]. In complex setups like Docker-in-Docker (DinD), it is often necessary to explicitly ensure that any required data resides within this daemon-visible workspace path to allow for bind-mounting [4]. Usage: It is the recommended location for transient state, intermediate outputs, and temporary files that must persist across steps within the same job but do not need to be stored in the repository checkout [10][2].Citations:
🌐 Web query:
GitHub Actions runner source HostContext WellKnownDirectory Temp _work _temp GITHUB_STEP_SUMMARY💡 Result:
In GitHub Actions, the runner manages various directories and environment variables to facilitate job execution [1][2][3]. HostContext and WellKnownDirectory The GitHub Actions runner uses a component called HostContext to manage system paths [1][2]. It defines a set of WellKnownDirectory constants that identify key locations on the runner's filesystem [1][2]. These include: - Root: The base directory of the runner installation [1][2]. - Work: The directory where workflow job workspaces are created (often referenced as _work) [1][2][4]. - Temp: A dedicated directory for temporary files, typically resolved as _temp within the runner's work structure [1][5][2]. _work and _temp - _work: This directory serves as the root for job workspaces, repository checkouts, and runner-related metadata [4][6][3]. - _temp: Within the runner, this path (often exposed via the RUNNER_TEMP environment variable) is used for various transient tasks, including storing temporary scripts and managing inter-process communication via file commands [5][4][3]. - Inside _temp, the runner maintains a specific directory named _runner_file_commands [7][4]. This hidden directory is critical for the "file command" system, which allows steps to communicate state, environment variable changes, and outputs back to the runner [7][4]. GITHUB_STEP_SUMMARY - GITHUB_STEP_SUMMARY is an environment variable that provides the path to a specific file used for generating custom Markdown job summaries [8][9][10]. - When a step writes Markdown content to the file located at this path, the runner processes and displays that content on the workflow run's summary page [9][10]. - The path is unique to each step within a job [11][12]. The files are typically located within the _runner_file_commands directory inside the runner's _temp folder (e.g.,.../_temp/runner_file_commands/step_summary.txt) [5][11][4]. Summary of Key Relationships The runner uses the file command system to bridge the gap between user-executed steps and the runner process [7][10]. By appending data to files like the one pointed to by GITHUB_STEP_SUMMARY (or GITHUB_ENV, GITHUB_OUTPUT, etc.), steps can pass structured data back to the runner for subsequent processing or rendering [8][9][4].
Citations:
🌐 Web query:
GitHub-hosted Ubuntu runner df -h /home/runner/work /usr/share/dotnet same filesystem💡 Result:
On standard GitHub-hosted Ubuntu runners, /home/runner/work and /usr/share/dotnet are typically located on the same filesystem [1]. The /home/runner/work directory serves as the default workspace where your repository code is checked out and actions execute [2][1], while /usr/share/dotnet is the standard pre-installed location for the.NET SDKs and runtimes on these images [3][1]. Because these paths generally reside on the same root filesystem (often mounted as /), they share the same disk space allocation and filesystem characteristics [1]. However, users occasionally encounter permission issues when attempting to modify /usr/share/dotnet—such as when a workflow tries to install or update.NET versions—because the default "runner" user may not have write permissions to that system-level directory, depending on the specific runner image configuration [4][3][5]. To resolve these conflicts, it is recommended to use the DOTNET_INSTALL_DIR environment variable to point to a user-writable directory (e.g., within /home/runner/) instead of the system default [4][6][7]. Note: The specific ownership and permission structure of directories like /usr/share/ can change across different runner image versions [8]. Always check the latest environment variables provided by GitHub Actions to manage paths dynamically rather than relying on static system paths [2].
Citations:
🌐 Web query:
site:github.com/actions/runner-images "/home/runner/work" "/usr/share/dotnet" "df -h"💡 Result:
The command df -h is a standard Linux utility used to display the amount of available disk space on file systems [1][2][3]. The -h flag stands for human-readable, which formats output sizes in powers of 1024 (e.g., KB, MB, GB) instead of raw byte counts [1][3]. In the context of the paths you provided: 1. /home/runner/work: This is the default workspace directory on GitHub-hosted runners where your repository code is checked out and where your build/workflow artifacts are typically generated [4][5]. 2. /usr/share/dotnet: This is the standard installation directory for the.NET SDK and runtime on GitHub-hosted Linux runners [6][5]. Users frequently run df -h in GitHub Actions workflows to diagnose "No space left on device" errors [1][2][3]. Because GitHub-hosted runners have a finite, guaranteed amount of free disk space (typically around 14 GB) [7][8][9], workflows that generate large build artifacts or cache large dependencies may exhaust this space [7][2][10]. A common workaround for disk space issues in these environments is to delete large, unused directories—such as /usr/share/dotnet—to reclaim space, though this prevents the use of.NET tools in subsequent steps of that job [2][8][3].
Citations:
Make the diagnostic writes non-gating.
On standard GitHub-hosted Ubuntu runners,
$GITHUB_STEP_SUMMARYis on the same filesystem as the reclaimed paths. If that filesystem is full, the first summary redirection can fail. Bash-ethen exits beforesudo rm -rfruns. Guard both summary writes with|| trueso cleanup does not depend on summary capacity.🤖 Prompt for AI Agents