Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/hyperledger-iroha/iroha/env_var_migration.jagit clone --depth 1 https://github.com/hyperledger-iroha/irohaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/hyperledger-iroha/iroha/env_var_migration.ja)<a href="https://agentmods.dev/agents/hyperledger-iroha/iroha/env_var_migration.ja"><img src="https://agentmods.dev/badge/agents/hyperledger-iroha/iroha/env_var_migration.ja.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.02024 |
| Opus 5 | $0.00000 | $0.01012 |
| Sonnet 5 | $0.00000 | $0.00405 |
| Haiku 4.5 | $0.00000 | $0.00202 |
Grade A, and why
env_var_migration.ja scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Env → Config 移行トラッカー
このトラッカーは docs/source/agents/env_var_inventory.{json,md} に示される
本番向けの環境変数トグルと、iroha_config への移行(または dev/test 専用への
明示的スコープ)計画を要約する。
注記: ci/check_env_config_surface.sh は、AGENTS_BASE_REF と比較して新しい
本番 環境 shim が現れた場合に失敗する。ENV_CONFIG_GUARD_ALLOW=1 が
設定されていない限り、意図的な追加はここに記載してから override を使用すること。
完了した移行
- IVM ABI opt-out —
IVM_ALLOW_NON_V1_ABIを削除。コンパイラは非 v1 ABI を 無条件に拒否し、ユニットテストでエラーパスを保護する。 - IVM debug banner env shim —
IVM_SUPPRESS_BANNERの env opt-out を廃止。 バナー抑制はプログラム的 setter で引き続き利用可能。 - IVM cache/sizing — cache/prover/GPU sizing を
iroha_configに移行 (pipeline.{cache_size,ivm_cache_max_decoded_ops,ivm_cache_max_bytes,ivm_prover_threads},accel.max_gpus) し、ランタイム env shim を削除。ホストはivm::ivm_cache::configure_limitsとivm::zk::set_prover_threadsを呼び、 テストは env override の代わりにCacheLimitsGuardを使う。 - Connect queue root — クライアント設定に
connect.queue.root(デフォルト:~/.iroha/connect) を追加し、CLI と JS 診断へ配線。 JS ヘルパーは設定(または明示的rootDir)を解決し、allowEnvOverrideを通じて dev/test でのみIROHA_CONNECT_QUEUE_ROOTを尊重する。 テンプレートにノブを記載し、運用者は env override を不要にする。 - Izanami network opt-in — Izanami chaos ツールに明示的な
allow_netCLI/config フラグを追加。実行はallow_net=true/--allow-netが必須となり、 - IVM banner beep —
IROHA_BEEPenv shim をivm.banner.{show,beep}(デフォルト: true/true)に置換。バナー/ビープの配線は本番で 設定のみを読む。dev/test ビルドでは手動トグルのため env override を尊重する。 - DA spool override (tests only) —
IROHA_DA_SPOOL_DIRはcfg(test)の ヘルパー内に限定。本番コードは常に設定から spool パスを取得する。 - Crypto intrinsics —
IROHA_DISABLE_SM_INTRINSICS/IROHA_ENABLE_SM_INTRINSICSをcrypto.sm_intrinsicsポリシー(auto/force-enable/force-disable)に置換し、IROHA_SM_OPENSSL_PREVIEWガードを削除。ホストは起動時にポリシーを適用し、 bench/test はCRYPTO_SM_INTRINSICSで opt-in 可能。OpenSSL preview は 設定フラグのみを尊重する。Izanami は既に--allow-net/永続設定を要求し、 テストは env トグルではなくそのノブに移行済み。 - FastPQ GPU tuning —
fastpq.metal.{max_in_flight,threadgroup_width,metal_trace,metal_debug_enum,metal_debug_fused}を追加(デフォルト:None/None/false/false/false)し CLI 解析へ配線。FASTPQ_METAL_*/FASTPQ_DEBUG_*shim は dev/test の fallback として動作し、 設定読み込み後は(未設定でも)無視される。ドキュメント/在庫は移行を示すため更新済み。 【crates/irohad/src/main.rs:2609】【crates/iroha_core/src/fastpq/lane.rs:109】【crates/fastpq_prover/src/overrides.rs:11】 (IVM_DECODE_TRACE,IVM_DEBUG_WSV,IVM_DEBUG_COMPACT,IVM_DEBUG_INVALID,IVM_DEBUG_REGALLOC,IVM_DEBUG_METAL_ENUM,IVM_DEBUG_METAL_SELFTEST,IVM_FORCE_METAL_ENUM,IVM_FORCE_METAL_SELFTEST_FAIL,IVM_FORCE_CUDA_SELFTEST_FAIL,IVM_DISABLE_METAL,IVM_DISABLE_CUDA) は共有ヘルパーで debug/test ビルドにのみ ゲートされ、本番バイナリは無視する一方、ローカル診断用ノブは維持される。 env 在庫は dev/test 専用スコープを反映するよう再生成された。 - FASTPQ fixture updates —
FASTPQ_UPDATE_FIXTURESは FASTPQ 統合テストにのみ存在。 本番ソースは env トグルを読まなくなり、在庫は test-only を反映する。 - Inventory refresh + scope detection — env 在庫ツールは
build.rsを build スコープとして タグ付けし、#[cfg(test)]/integration harness を追跡する。これにより test-only トグル (例:IROHA_TEST_*,IROHA_RUN_IGNORED)や CUDA build フラグが production カウント外に 反映される。2025-12-07 に在庫を再生成(518 refs / 144 vars)。 - P2P topology env shim release guard —
IROHA_P2P_TOPOLOGY_UPDATE_MSは release ビルドで 決定論的な起動エラーを発生(debug/test では warn のみ)し、本番ノードはnetwork.peer_gossip_period_msのみに依存する。env 在庫はガードと分類器更新を反映する。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 97 lines · 0 tokens per session scan A 2301e84cfc12
env_var_migration.ja is an agent published in the GitHub repository hyperledger-iroha/iroha (488 stars, last pushed yesterday), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 2,024 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-01.
Other agents, from other repositories
deploy-preflight
Verifies a three.ws production deploy is safe to run BEFORE gcloud builds submit. Checks the load-bearing build order, worktree artifacts, service-account pins, and changelog wiring. Use before any deploy or when a deploy failed mid-build.
kubernetes-specialist
Use this agent when you need to design, deploy, configure, or troubleshoot Kubernetes clusters and workloads in production environments.
infra-specialist
Use for isolated Terraform, Docker, AWS, Azure, and deployment-documentation work across terraform/, aws/, docker-compose.yml, DEPLOYMENT.md, and agenticai/deployments/.
fleet-intake
Non-interactive setup agent that writes a server profile from caller-supplied connection details, deploys the plugin SSH key, runs discovery, and updates the inventory.
deploy-to-staging
Use this agent PROACTIVELY when deploying applications to staging or QA environments. This includes running test suites before deployment, building production bundles, creating Docker images, pushing to container registries, deploying to Kubernetes staging namespaces, and running smoke tests. Invoke when someone says…
Deployer Agent
Owns the deployment pipeline, CI/CD setup, environment configuration, release checklists, and MCP tool connections.