tootootootoolinglinglingling

Author: frantic1048

orders/codex/order.ncl

@@ -0,0 +1,13 @@
+let { Order, .. } = import "../order.contract.ncl" in
+{
+  blend = {
+    files = [
+      {
+        from_file = "skills/local-tooling",
+        symlink = true
+      },
+    ],
+
+    prefix = ["~/.codex"],
+  },
+} | Order

orders/codex/skills/local-tooling/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: local-tooling
+description: Use when Codex needs to choose, inspect, or troubleshoot this user's local shell behavior, Vanilla dotfiles and Blend-managed config, filesystem search tools, language runtimes, package managers, PATH/toolchain issues, or platform CLIs on their macOS arm64 and Arch Linux x86_64 machines. Trigger for questions or tasks involving elvish, nushell, zsh/bash/sh availability, Vanilla dotfiles, blend view, proto, rust/cargo paths, Homebrew/pacman language tools, gh, glab, twg, pup, sentry, ripgrep, fd, or machine-specific command selection.
+---
+
+# Local Tooling
+
+Use this skill to pick commands that fit the user's machines instead of assuming a generic Unix setup. Prefer durable conventions from the user's dotfiles, then verify current state before running version-sensitive commands.
+
+## Quick Start
+
+1. Treat `~/Vanilla` as the primary dotfiles checkout. It is normally present at that path across OSes.
+2. Treat Vanilla configs as Blend-managed. Use `blend view` from `~/Vanilla` for read-only dotfile inspection, and do not run other Blend commands unless the user explicitly asks.
+3. For environment/PATH questions, inspect `~/.local/bin/van/shellenv` and `~/.local/bin/van/shellenv.nu` first. `~/.local/bin/van` points through `~/Vanilla/bin`, which is a repo-level symlink to the physical Blend-managed script Source at `~/Vanilla/orders/bin/bin`.
+4. Prefer nushell for new scripts when reasonable. Prefer elvish only for interactive-shell context or existing elvish scripts.
+5. Prefer `rg` and `fd` for filesystem discovery when installed.
+6. Prefer proto-managed language toolchains when possible. Avoid Homebrew/pacman language runtimes for version-sensitive work.
+7. Prefer platform CLIs such as `gh`, `glab`, `twg`, `pup`, and `sentry` when installed and configured, but verify auth/config with a small read before relying on them.
+
+## References
+
+- Read `references/shell.md` for shell choice, dotfiles layout, and environment setup.
+- Read `references/dotfiles.md` for Vanilla/Blend dotfile inspection and safety rules.
+- Read `references/filesystem.md` for file and text search preferences.
+- Read `references/toolchains.md` for proto, Rust, package managers, PATH, and language-runtime decisions.
+- Read `references/platform-clis.md` for GitHub, GitLab, Atlassian, Datadog, and Sentry CLI handling.
+
+## Validation
+
+When current machine state matters, run `scripts/inspect-local-tooling.nu` if `nu` is available. Use its output as a snapshot, not as permanent truth.
+
+If the active PATH appears to contradict this skill, do not silently build a one-off workaround. Mention the mismatch, use `~/.local/bin/van/shellenv` as the expected environment source, and ask the user if the mismatch should be fixed in dotfiles.

orders/codex/skills/local-tooling/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Local Tooling"
+  short_description: "Machine shell and toolchain conventions"
+  default_prompt: "Use $local-tooling to inspect this machine’s shell, CLI, and language toolchain conventions before choosing commands."

orders/codex/skills/local-tooling/references/dotfiles.md

@@ -0,0 +1,56 @@
+# Vanilla Dotfiles And Blend
+
+## Source Of Truth
+
+- The user's dotfiles repo is `~/Vanilla`, hosted as `frantic1048/Vanilla`.
+- The repo is managed by the user's own tool `blend`, implemented in `~/Vanilla/blend`.
+- Most config packages live under `~/Vanilla/orders/<order-name>/`.
+- User scripts are physically sourced from `~/Vanilla/orders/bin/bin`; `~/Vanilla/bin` is a repo-level symlink kept as the stable entrypoint and contains `bin/blend` as a symlink to the built Blend binary.
+- Each order's deployment shape is described by its `order.ncl`.
+- Read `~/Vanilla/blend/README.md`, `~/Vanilla/NEW_BLEND.md`, and `~/Vanilla/blend/src/` when deeper Blend behavior matters.
+
+## Rendered Versus Symlinked Config
+
+Blend supports both render/copy-to-target and symlink-to-target modes.
+
+- Most orders use render/copy-to-target mode.
+- Rendered target files can drift from the source files in `~/Vanilla`.
+- Symlinked entries can be identified in `order.ncl` with `symlink = true` or by `blend view` output showing a symlink relationship.
+- Do not assume source files and live system config are identical. Verify the order and target relationship first.
+
+## Inspecting Orders
+
+Prefer read-only inspection:
+
+```sh
+cd ~/Vanilla
+blend view
+blend view nushell
+```
+
+- Run `blend view` with `PWD=~/Vanilla` when possible. Outside the repo, Blend may use its state directory from the last successful run to locate orders, which is useful but less explicit.
+- `blend view` without an order name lists all discovered orders and their source-to-target relationships.
+- `blend view <order-name>` focuses one order.
+- The output shows target paths, symlink status, no-change status, and source/target diffs.
+- In Codex sandboxed sessions, `blend view` may print a sandbox initialization warning and still exit successfully with useful output. Treat this as a warning, not a failure, when the command exit code is zero.
+
+## Safety Boundary
+
+Use only `blend view` for routine Codex inspection.
+
+Do not run other Blend commands unless the user explicitly asks, because other commands may write to target config, update state, create snapshots, sync, or otherwise mutate the system.
+
+## Reading `order.ncl`
+
+When `blend view` is unavailable or more detail is needed, read `~/Vanilla/orders/<order-name>/order.ncl`.
+
+Useful fields:
+
+- `prefix`: target directory prefix, often OS-specific.
+- `files`: deployed files or directories.
+- `from_file`: source file or directory inside the order.
+- `from_config`: inline structured config rendered to a target file.
+- `name`: target filename override.
+- `when`: OS, architecture, hostname, or similar condition.
+- `symlink`: whether the target should be a symlink instead of rendered/copied content.
+- `exclude`: files skipped when deploying a source directory.

orders/codex/skills/local-tooling/references/filesystem.md

@@ -0,0 +1,17 @@
+# Filesystem Search
+
+## Preferred Tools
+
+- Use `rg` for text search.
+- Use `rg --files` for fast file listing when the task is repo/file discovery.
+- Use `fd` for filesystem finding when name, extension, depth, or type filters make it clearer than `rg --files`.
+
+## Fallbacks
+
+- If `rg` or `fd` are not installed on the current machine, fall back to standard tools already available in the task environment.
+- Avoid adding dependencies just to search files.
+
+## Command Style
+
+- Keep discovery commands narrow and readable.
+- When searching dotfiles, start in `~/Vanilla` and the relevant `orders/` subdirectory if the topic is known.

orders/codex/skills/local-tooling/references/platform-clis.md

@@ -0,0 +1,27 @@
+# Platform CLIs
+
+## Preference
+
+Prefer platform CLIs when installed and configured, because they usually give more accurate live state than manual web or filesystem inference.
+
+Common CLIs:
+
+- `gh` for GitHub
+- `glab` for GitLab
+- `twg` for Atlassian/Jira/Confluence/internal work graph tasks
+- `pup` for Datadog
+- `sentry` for Sentry
+
+## Verification
+
+These CLIs may not always be installed or authenticated on every machine. Before promising live operations, run a small non-mutating check:
+
+- `command -v <tool>`
+- a read-only auth/status command when available
+- a small read against the relevant host/project when auth status is known to be unreliable
+
+## Failure Handling
+
+If a platform CLI exists but is unauthenticated or configured for the wrong host, report that directly and avoid inferring live state from stale local context.
+
+For GitLab in particular, auth status and API behavior can diverge in some shells. Prefer proving a small authenticated read before planning a larger metadata refresh.

orders/codex/skills/local-tooling/references/shell.md

@@ -0,0 +1,43 @@
+# Shell And Environment
+
+## Dotfiles Source
+
+- The user's main dotfiles repo is `frantic1048/Vanilla`.
+- The local checkout is normally `~/Vanilla` on every OS.
+- Current migrated config lives under `~/Vanilla/orders/`.
+- `~/.local/bin/van` is expected to resolve through `~/Vanilla/bin`.
+- `~/Vanilla/bin` is a repo-level symlink to `~/Vanilla/orders/bin/bin`, the physical Blend-managed script Source directory.
+
+## Shell Choice
+
+- Elvish is the user's main interactive shell.
+- Existing elvish scripts may still exist, especially in `~/Vanilla/orders/bin/bin` and elvish config. `~/Vanilla/bin` should remain usable as the stable symlinked entrypoint.
+- Avoid writing new elvish scripts unless the task is specifically about elvish integration.
+- Prefer nushell for new local automation scripts because it has rich built-ins and useful static checking, which makes agent-authored scripts easier to debug.
+- Bash, sh, and zsh availability varies across the user's macOS arm64 and Arch Linux x86_64 machines. Use them for short POSIX-compatible commands, repo-native scripts, or when a tool explicitly requires them.
+
+## Environment Source
+
+- Treat `~/.local/bin/van/shellenv.nu` as the environment brain.
+- `~/.local/bin/van/shellenv` is a bash bootstrap wrapper that finds `nu`, then delegates to `shellenv.nu`.
+- Nushell config uses `use ~/.local/bin/van/shellenv.nu; shellenv apply`.
+- Elvish config evaluates `~/.local/bin/van/shellenv elvish`.
+- POSIX shells can use `~/.local/bin/van/shellenv posix`.
+
+## PATH Expectations
+
+The shellenv helper is expected to put user-managed paths before package-manager paths. Important early entries include:
+
+- `~/.cargo/bin`
+- `~/.local/share/pnpm`
+- `~/.proto/shims`
+- `~/.proto/bin`
+- `~/.proto/tools/node/globals/bin`
+- `~/.local/bin/van`
+- `~/.local/bin`
+
+On macOS, Homebrew paths such as `/opt/homebrew/bin` or `/usr/local/bin` are still appended for general CLI availability, but avoid relying on Homebrew language runtimes for version-sensitive work.
+
+## Drift Handling
+
+If `command -v` shows an unexpected package-manager runtime before the user-managed path, first check whether the command ran inside the expected shellenv. Prefer fixing `shellenv` or asking the user to fix it over repeating local PATH workarounds in every task.

orders/codex/skills/local-tooling/references/toolchains.md

@@ -0,0 +1,52 @@
+# Language Toolchains
+
+## Proto
+
+- Prefer proto-managed language tools when possible.
+- The user syncs proto configuration from `~/Vanilla/orders/proto/.proto/.prototools` to `~/.proto/.prototools`.
+- Read `~/.proto/.prototools` for the current global proto-managed versions.
+- Run `proto status` or targeted version commands when current runtime versions matter.
+- `~/.proto/shims`, `~/.proto/bin`, and `~/.proto/tools/node/globals/bin` should normally be on PATH through `shellenv`.
+
+## Current Verified Proto File Shape
+
+As of the first creation of this skill, `~/.proto/.prototools` and `~/Vanilla/orders/proto/.proto/.prototools` matched and included:
+
+- `bun`
+- `deno`
+- `go`
+- `proto`
+- `python`
+- `rust`
+- `uv`
+- `npm`
+- `node`
+- `pnpm`
+- `yarn`
+
+Do not treat these versions as permanent. Re-read the file before making version-specific claims.
+
+## Rust
+
+- Rust is special: executables normally live in `~/.cargo/bin`, not only under `~/.proto/shims`.
+- `shellenv` should already put `~/.cargo/bin` early in PATH.
+- If `command -v cargo` or `command -v rustc` points to Homebrew/pacman unexpectedly, check whether shellenv has been applied before working around it.
+
+## Package-Manager Runtimes
+
+- Avoid Homebrew/pacman-sourced language tools for version-sensitive work. They are harder to manage consistently and can have side effects with other package-manager packages.
+- Package-manager CLIs are fine for platform utilities and OS packages, but prefer proto or repo-local pins for language runtimes and package managers.
+- If PATH or runtime selection looks weird, tell the user. The user prefers fixing the shared environment source over accumulating Codex-specific workarounds.
+
+## Repository-Specific Pins
+
+Always respect repo-local version files and package-manager metadata over global defaults. Common examples include:
+
+- `.node-version`
+- `.python-version`
+- `.dvmrc`
+- `.prototools`
+- `packageManager` in `package.json`
+- Rust toolchain files
+
+Use native tool-specific version files when present. Use `.prototools` as the fallback for tools without a native version file.

orders/codex/skills/local-tooling/scripts/inspect-local-tooling.nu

@@ -0,0 +1,67 @@
+#!/usr/bin/env nu
+
+let tools = [
+  rg
+  fd
+  blend
+  proto
+  cargo
+  rustc
+  node
+  npm
+  pnpm
+  deno
+  bun
+  uv
+  python
+  gh
+  glab
+  twg
+  pup
+  sentry
+  nu
+  elvish
+  bash
+  zsh
+  sh
+]
+
+let tool_rows = ($tools | each {|tool|
+  let resolved = (which $tool | first | default null)
+  {
+    tool: $tool
+    path: (if $resolved == null { null } else { $resolved.path })
+  }
+})
+
+let proto_file = ($nu.home-dir | path join ".proto" ".prototools")
+let vanilla_proto_file = ($nu.home-dir | path join "Vanilla" "orders" "proto" ".proto" ".prototools")
+let shellenv = ($nu.home-dir | path join ".local" "bin" "van" "shellenv")
+let shellenv_nu = ($nu.home-dir | path join ".local" "bin" "van" "shellenv.nu")
+let vanilla_bin = ($nu.home-dir | path join "Vanilla" "bin")
+let vanilla_bin_source = ($nu.home-dir | path join "Vanilla" "orders" "bin" "bin")
+
+{
+  os: $nu.os-info
+  vanilla: {
+    path: ($nu.home-dir | path join "Vanilla")
+    exists: (($nu.home-dir | path join "Vanilla") | path exists)
+    bin_entrypoint: $vanilla_bin
+    bin_entrypoint_exists: ($vanilla_bin | path exists)
+    bin_source: $vanilla_bin_source
+    bin_source_exists: ($vanilla_bin_source | path exists)
+  }
+  shellenv: {
+    wrapper: $shellenv
+    wrapper_exists: ($shellenv | path exists)
+    nushell_module: $shellenv_nu
+    nushell_module_exists: ($shellenv_nu | path exists)
+  }
+  proto: {
+    home_file: $proto_file
+    home_file_exists: ($proto_file | path exists)
+    vanilla_file: $vanilla_proto_file
+    vanilla_file_exists: ($vanilla_proto_file | path exists)
+  }
+  tools: $tool_rows
+}

orders/git/git/config

@@ -33,6 +33,8 @@
 [rebase]
 	autoSquash = true
 	instructionFormat = "%aN\t%s"
+[branch]
+	autoSetupMerge = simple
 [http]
 	postBuffer = 1048576000