Back to Details

secrets-management

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Secrets Management

Secret 管理

application / serviceのsecret管理を、人間・agent・CI/CDが同じauthority modelで扱えるようにする。
current default providerはInfisicalで、current default control planeはself-hosted 
https://secrets.rebuildup.dev
だが、目的はprovider adoptionそのものではない。守るべき性質は、secret valueのcanonical authority、least privilege、plaintext persistence回避、schema discoverability、recoverability、agent-safe evidenceである。
原則:
Secret values live in the secret provider. Secret contracts live in the repository. Access is identity-scoped and injected only where needed.
使 application / service 的 Secret 管理能够由人员、agent、CI/CD 在同一 authority model 下处理。
current default provider 为 Infisical，current default control plane 为 self-hosted 
https://secrets.rebuildup.dev
，但目标并非 provider adoption 本身。需要守住的性质包括：Secret 值的 canonical authority、least privilege、避免明文持久化、schema 可发现性、可恢复性以及 agent-safe evidence。
原则:
Secret 值存放在 Secret provider 中。Secret contract 存放在 repository 中。访问权限按身份限定，并仅在必要位置注入。

1. Responsibility boundary

1. 责任边界

このSkillが所有する:
  • application / service env secretのSoT設計
  • Infisical project / environment / path構成
  • repository-controlled env schemaとの分離
  • local CLI workflow
  • Machine Identity / human identityの責務分離
  • GitHub Actions OIDC integration
  • agent / workerへのsecret capability付与
  • plaintext 
    .env
    / GitHub Secrets / SOPS等からのmigration
  • secret-safe validation / evidence
  • provider unavailable時のdeviation評価
このSkillが所有しない:
  • application固有のcredential発行元でのrotation semantics
  • cloud IAM全体のarchitecture
  • vulnerability hunting全般
  • production secret値そのもののレビュー
  • security/privacy risk acceptance
接続先:
  • unknown secret-handling vulnerability -> 
    security-audit
  • GitHub workflow / delivery -> 
    github-delivery
  • worker isolation / credential injection boundary -> 
    sandbox-runtime
  • runtime validation -> 
    quality-gate
  • provider selection deviation / security-cost decision -> 
    engineering-decisions
  • durable recovery -> 
    agent-recovery
本 Skill 负责:
  • application / service 环境 Secret 的 SoT 设计
  • Infisical project / environment / path 结构
  • 与 repository-controlled env schema 的分离
  • local CLI workflow
  • Machine Identity / human identity 的职责分离
  • GitHub Actions OIDC integration
  • 向 agent / worker 授予 Secret capability
  • 从 plaintext 
    .env
    / GitHub Secrets / SOPS 等迁移
  • Secret-safe validation / evidence
  • provider unavailable 时的 deviation 评估
本 Skill 不负责:
  • application 特有 credential issuer 的 rotation semantics
  • 整体 cloud IAM architecture
  • 通用 vulnerability hunting
  • production Secret 值本身的审查
  • security / privacy risk acceptance
连接目标:
  • 未知的 secret-handling vulnerability -> 
    security-audit
  • GitHub workflow / delivery -> 
    github-delivery
  • worker isolation / credential injection boundary -> 
    sandbox-runtime
  • runtime validation -> 
    quality-gate
  • provider selection deviation / security-cost decision -> 
    engineering-decisions
  • durable recovery -> 
    agent-recovery

2. Canonical authority split

2. Canonical authority 拆分

secret valueとenvironment contractを同じSoTへ押し込まない。
不要将 Secret 值和 environment contract 强制放入同一个 SoT。

Secret value

Secret value

current application/service default:
text
Infisical (current default: https://secrets.rebuildup.dev)
└─ project
   ├─ dev
   ├─ staging
   └─ prod
Infisical側がcanonical value authorityを持つ。
current application/service default:
text
Infisical (current default: https://secrets.rebuildup.dev)
└─ project
   ├─ dev
   ├─ staging
   └─ prod
Infisical 侧拥有 canonical value authority。

Secret contract

Secret contract

repository側が次をcanonicalに持つ。
  • key name
  • required / optional
  • type / shape
  • non-secret default
  • environment applicability
  • owning component
  • validation rule
  • description that does not reveal the value
project stackに応じてtyped env schema、config schema、
.env.example
、generated metadata等を使用する。
.env.example
を使う場合はreal secretを入れず、placeholder / empty value / non-secret defaultだけを置く。
fresh agentがInfisicalのsecret valueを読むことなく、必要keyとvalidation contractを理解できる状態を維持する。
repository 侧对以下内容拥有 canonical authority:
  • key name
  • 必填 / 可选
  • type / shape
  • non-secret default
  • environment applicability
  • owning component
  • validation rule
  • 不暴露具体值的 description
根据 project stack，使用 typed env schema、config schema、
.env.example
、generated metadata 等。
使用 
.env.example
时，不得放入 real Secret，只能放置 placeholder / empty value / non-secret default。
应确保 fresh agent 无需读取 Infisical 中的 Secret 值，也能理解所需 key 和 validation contract。

3. When Infisical is the default

3. Infisical 何时作为 default

次を満たすapplication / serviceではInfisicalをdefaultとする。
  • runtimeがenvironment secretを必要とする
  • developer / CI / deployment等、複数principalからaccessする可能性がある
  • secret valueをGit historyへ置く必要がない
  • online secret providerへ到達できる
次はautomatic adoption対象にしない。
  • NixOS / dotfiles / bootstrap等でencrypted secret-in-Gitがexplicit requirement
  • offline-first runtime
  • provider-native storeだけを使う明確なplatform requirement
  • regulation / hosting / network constraintでInfisicalを利用できない
deviationはprovider名ではなく、同等以上のguaranteeで評価する。
对于满足以下条件的 application / service，将 Infisical 作为 default。
  • runtime 需要 environment Secret
  • developer / CI / deployment 等多个 principal 可能需要访问
  • 无需将 Secret 值放入 Git history
  • 可以访问 online Secret provider
以下情况不作为 automatic adoption 对象。
  • NixOS / dotfiles / bootstrap 等明确要求 encrypted secret-in-Git
  • offline-first runtime
  • 有明确的 platform requirement，仅使用 provider-native store
  • 因 regulation / hosting / network constraint 无法使用 Infisical
评估 deviation 时不看 provider 名称，而应评估是否具备同等或更强的 guarantee。

4. Initialization / reconciliation

4. 初始化 / 状态协调

初期化時は作成前にcurrent stateを調査する。
確認:
  1. env schema / validation source
  2. .env
    / 
    .env.*
    / secret-like config
  3. .gitignore
  4. GitHub Actions secrets / variablesへの依存
  5. existing secret manager / SOPS / cloud secret store
  6. runtime / deploy environment
  7. CI jobs that actually require secret access
  8. developer bootstrap path
  9. repository visibility and agent/runtime trust boundaries
desired state:
text
repository
├─ source
├─ env schema / non-secret metadata
├─ provider pointer/config
│  ├─ site/API endpoint
│  ├─ project ID
│  └─ environment/path mapping
└─ no canonical plaintext secret

Infisical
└─ canonical secret values

human / agent / CI
└─ scoped identity
   └─ runtime injection
idempotentに:
initialize if missing -> repair if incomplete -> update if stale -> verify if already correct
を適用する。
初始化时，在创建之前先调查 current state。
检查:
  1. env schema / validation source
  2. .env
    / 
    .env.*
    / 类似 Secret 的 config
  3. .gitignore
  4. 对 GitHub Actions secrets / variables 的依赖
  5. 现有 secret manager / SOPS / cloud secret store
  6. runtime / deploy environment
  7. 实际需要 Secret 访问权限的 CI jobs
  8. developer bootstrap path
  9. repository visibility 和 agent/runtime trust boundaries
desired state:
text
repository
├─ source
├─ env schema / non-secret metadata
├─ provider pointer/config
│  ├─ site/API endpoint
│  ├─ project ID
│  └─ environment/path mapping
└─ no canonical plaintext secret

Infisical
└─ canonical secret values

human / agent / CI
└─ scoped identity
   └─ runtime injection
幂等地应用:
initialize if missing -> repair if incomplete -> update if stale -> verify if already correct

5. CLI-first human workflow

5. CLI-first 人员工作流

Web UIをnormal workflowの必須surfaceにしない。
current default instance:
text
site: https://secrets.rebuildup.dev
api:  https://secrets.rebuildup.dev/api
標準bootstrap:
bash
export INFISICAL_API_URL=https://secrets.rebuildup.dev/api
infisical login --domain=https://secrets.rebuildup.dev
infisical init
ただしtracked project bindingが既に存在するrepositoryでは 
infisical init
をfresh setupのたびに再実行しない。existing bindingを検証し、欠落・stale時だけreconcileする。
provider pointer/configにsecret valueを含めないことを確認し、current defaultで使用するsite/API URL、project ID、environment/path mapping等のsafe metadataをrepositoryからdiscoverableにする。
wrapper / task / CIはcurrent provider endpointを明示し、Infisical CLIのvendor default endpointへ暗黙fallbackさせない。current default profileでmanaged Cloudへ意図せず接続するのはconfiguration driftとして扱う。
通常実行:
bash
INFISICAL_API_URL=https://secrets.rebuildup.dev/api \
  infisical run --env=dev --path=/backend -- <command>
projectにstable local command interfaceがある場合は、provider-specific invocationを薄く包んでよい。
例:
text
env:run <command>
env:check
env:schema
wrapperはsecret valueをprint/exportせず、underlying provider failureを隠さない。
Web UIはinspection / emergency administration / onboarding / access review等に使用できるが、agentや通常developer taskの必須stepとして文書化しない。
不要将 Web UI 作为 normal workflow 的必需 surface。
current default instance:
text
site: https://secrets.rebuildup.dev
api:  https://secrets.rebuildup.dev/api
标准 bootstrap:
bash
export INFISICAL_API_URL=https://secrets.rebuildup.dev/api
infisical login --domain=https://secrets.rebuildup.dev
infisical init
但是，对于已存在 tracked project binding 的 repository，不要在每次 fresh setup 时重新执行 
infisical init
。应验证 existing binding，仅在缺失或 stale 时进行 reconcile。
确认 provider pointer/config 不包含 Secret 值，并确保 current default 使用的 site/API URL、project ID、environment/path mapping 等 safe metadata 可从 repository 中发现。
wrapper / task / CI 应明确指定 current provider endpoint，不得隐式 fallback 到 Infisical CLI 的 vendor default endpoint。将 current default profile 意外连接到 managed Cloud 视为 configuration drift。
常规执行:
bash
INFISICAL_API_URL=https://secrets.rebuildup.dev/api \
  infisical run --env=dev --path=/backend -- <command>
如果 project 存在 stable local command interface，可以对 provider-specific invocation 进行轻量封装。
示例:
text
env:run <command>
env:check
env:schema
wrapper 不得 print/export Secret 值，也不得隐藏 underlying provider failure。
Web UI 可用于 inspection / emergency administration / onboarding / access review 等，但不应将 agent 或常规 developer task 记录为必须经过 Web UI 的步骤。

Control-plane automation

Control-plane automation

project / environment / path / Machine Identity / permission / OIDC trust等も、可能な範囲でheadlessにreconcileできるようにする。
優先順位:
  1. Infisical CLIで安全に操作できるsurface
  2. official API
  3. Terraform / OpenTofu等のofficial provider
  4. Web UIはbootstrap / inspection / emergency fallback
control-plane configurationをIaCへ置く場合、repositoryにはproject ID、identity ID、environment/path、role/policy等のnon-secret stateだけを置く。secret valueやlong-lived auth credentialをTerraform/OpenTofu stateへpersistさせない。provider capabilityがtime-sensitiveな場合はcurrent official documentationを確認する。
Web UIでしか行えなかった操作がある場合も、その事実と必要なresultをdurable documentationへ残し、画面操作そのものを唯一のrecoverability sourceにしない。
project / environment / path / Machine Identity / permission / OIDC trust 等也应尽可能通过 headless 方式进行 reconcile。
优先级:
  1. 可通过 Infisical CLI 安全操作的 surface
  2. official API
  3. Terraform / OpenTofu 等 official provider
  4. Web UI 仅作为 bootstrap / inspection / emergency fallback
将 control-plane configuration 放入 IaC 时，repository 中只应存放 project ID、identity ID、environment/path、role/policy 等 non-secret state。不得将 Secret 值或 long-lived auth credential 持久化到 Terraform/OpenTofu state 中。如果 provider capability 具有时效性，应查阅 current official documentation。
即使某些操作只能通过 Web UI 完成，也应将这一事实和必要结果记录在 durable documentation 中，不能将界面操作本身作为唯一的 recoverability source。

6. Plaintext materialization

6. 明文实体化

runtime injectionを優先する。
平文
.env
やexport fileがtool compatibility上必要な場合だけmaterializeする。
必須条件:
  • Git対象外
  • pathが明示的にgitignored
  • lifecycleがtask/runtimeにbounded
  • file permissionを可能な範囲で絞る
  • logs / Issue / PR / checkpointへvalueを出さない
  • 不要になったcopyを残さない
plain 
.env
をcanonical storeやonboarding distribution artifactとして扱わない。
优先采用 runtime injection。
仅当 tool compatibility 确实需要时，才实体化明文 
.env
或 export file。
必须满足以下条件:
  • 不属于 Git 目标范围
  • path 已明确加入 gitignore
  • lifecycle 限定在 task/runtime 范围内
  • 尽可能收紧 file permission
  • 不向 logs / Issue / PR / checkpoint 输出值
  • 不保留不再需要的 copy
不要将 plain 
.env
视为 canonical store 或 onboarding distribution artifact。

7. Agent / worker access

7. Agent / worker 访问

agentへ「Infisicalを使える」ことと「全secretを読める」ことを同義にしない。
default:
  • Coordinator / reviewer: secret accessなし
  • implementation worker: secret accessなし
  • local integrationで必要なworker: dev/testの必要pathだけread
  • deployment worker: target environmentの必要pathだけread
  • secret maintenance actor: explicit write scopeだけ
Machine Identity / temporary identityは最低限次でscopeする。
  • project
  • environment
  • path
  • action
  • secret name/tag when practical
  • lifetime / auth context when supported
Supervisorはhost userのbroad credentialをsandboxへ無条件inheritさせない。
secret accessが必要なら、そのworker capabilityとして明示的に付与する。
不要将“agent 可以使用 Infisical”与“agent 可以读取所有 Secret”视为同义。
default:
  • Coordinator / reviewer: 无 Secret access
  • implementation worker: 无 Secret access
  • local integration 所需的 worker: 只读 dev/test 的必要 path
  • deployment worker: 只读 target environment 的必要 path
  • secret maintenance actor: 仅具有 explicit write scope
Machine Identity / temporary identity 至少应按以下维度限定 scope。
  • project
  • environment
  • path
  • action
  • 可行时限定 secret name/tag
  • 支持时限定 lifetime / auth context
Supervisor 不得将 host user 的 broad credential 无条件继承到 sandbox 中。
如需 Secret access，应将其明确授予对应的 worker capability。

Forbidden agent behavior

禁止的 agent 行为

  • env
    等でenvironment全体をdumpする
  • secret list取得を目的なく行う
  • valueをchat / checkpoint / artifactへ転写する
  • debugging目的でsecret valueをlogへ出す
  • broader identityへ切り替えてpermission errorを回避する
permission不足はsecurity boundaryとして扱い、必要scopeを特定してから変更する。
  • 通过 
    env
    等命令 dump 整个 environment
  • 无目的地获取 Secret list
  • 将值转写到 chat / checkpoint / artifact
  • 以 debugging 为目的将 Secret 值写入 log
  • 切换到权限更广的 identity 来规避 permission error
将权限不足视为 security boundary，确定所需 scope 后再进行变更。

8. GitHub Actions

8. GitHub Actions

GitHub ActionsからInfisicalへaccessする場合、current platformが対応していればOIDC + Machine Identityをdefaultとする。current default profileではidentity/control planeを 
https://secrets.rebuildup.dev
側へ統一する。
desired trust chain:
text
GitHub Actions job
    ↓ short-lived OIDC token
Infisical Machine Identity
    ↓ scoped authorization
required environment/path secrets
標準:
  • GitHubにlong-lived Infisical master credentialを保存しない
  • workflowは必要なjobだけ 
    id-token: write
  • contents: read
    等、他permissionも最小化
  • OIDC issuer / subject / audience / repository / environment等をcurrent official contractに従ってrestrict
  • generic lint/test jobへproduction secretを渡さない
  • production accessはdeployment/release boundaryへ限定
  • identity ID / project slug等のnon-secret identifierはsecretとして扱わない
  • OIDCをworkflow source protectionの代替にしない
  • secret-bearing workflowはtrusted branch / protected environment / applicable review boundaryからだけ実行する
  • untrusted PR codeをsecret取得後に実行しない。特に 
    pull_request_target
    等、base-contextのcredentialとuntrusted head codeを混在させるtriggerは明示的にsecurity reviewする
OIDC非対応runtimeではUniversal Auth等をfallbackとして使用できるが、static credentialは最小scope、rotation可能、long-lived master keyではないものにする。
GitHub Actions / Infisical OIDCのclaim形式やofficial action syntaxはtime-sensitiveである。実装時にcurrent official documentationを確認し、古いexampleをblind copyしない。
从 GitHub Actions 访问 Infisical 时，如果 current platform 支持，应将 OIDC + Machine Identity 作为 default。在 current default profile 下，应将 identity/control plane 统一到 
https://secrets.rebuildup.dev
。
desired trust chain:
text
GitHub Actions job
    ↓ short-lived OIDC token
Infisical Machine Identity
    ↓ scoped authorization
required environment/path secrets
标准:
  • 不在 GitHub 中保存 long-lived Infisical master credential
  • 仅对必要的 job 授予 
    id-token: write
  • 同样将 
    contents: read
    等其他 permission 最小化
  • 按 current official contract 限制 OIDC issuer / subject / audience / repository / environment 等
  • 不向 generic lint/test job 传入 production Secret
  • 将 production access 限定在 deployment/release boundary
  • 不将 identity ID / project slug 等 non-secret identifier 视为 Secret
  • 不将 OIDC 作为 workflow source protection 的替代方案
  • 仅允许包含 Secret 的 workflow 从 trusted branch / protected environment / applicable review boundary 执行
  • 获取 Secret 后不得执行 untrusted PR code。尤其是 
    pull_request_target
    等将 base-context credential 与 untrusted head code 混合的 trigger，必须明确进行 security review
在 OIDC 不受支持的 runtime 中，可以使用 Universal Auth 等作为 fallback，但 static credential 必须具有最小 scope、可轮换，且不能是 long-lived master key。
GitHub Actions / Infisical OIDC 的 claim 格式和 official action syntax 具有时效性。实现时应查阅 current official documentation，不要盲目复制旧示例。

9. Environment / path model

9. Environment / path 模型

環境はproject実態へ合わせる。
標準候補:
text
dev
staging
prod
pathはdeployment/component boundaryを表現する。
例:
text
/shared
/web
/backend
/worker
/deploy
すべてのprojectへ固定pathを強制しない。
同じsecretを無秩序に複製するより、ownershipとconsumer boundaryを明確にする。
prod credentialをdevへcopyして動作確認することを標準化しない。
根据 project 的实际情况调整 environment。
标准候选项:
text
dev
staging
prod
path 用于表示 deployment/component boundary。
示例:
text
/shared
/web
/backend
/worker
/deploy
不要对所有 project 强制使用固定 path。
相比无序复制相同 Secret，更应明确 ownership 和 consumer boundary。
不要将复制 prod credential 到 dev 进行行为验证标准化。

10. Schema and drift verification

10. Schema 与 drift 验证

secret valueを取得せずに可能な検証を優先する。
最低限:
  • required keyがschemaに定義されている
  • provider上に必要keyが存在する
  • unknown/stale keyを検出できる
  • environment/path mappingがconsumerと一致する
  • required secretがgeneric CIへ露出していない
  • application startup時のenv validationがある場合は実行する
evidenceにはvalueではなく次を使用する。
  • key name
  • presence / absence
  • schema validation result
  • environment/path
  • identity scope
  • exit code
  • redacted/hash fingerprint when truly necessary
hashもsmall-domain secretの推測材料になり得るため、必要性がない場合は記録しない。
优先执行无需获取 Secret 值即可完成的验证。
最低要求:
  • required key 已在 schema 中定义
  • provider 上存在所需 key
  • 能够检测 unknown/stale key
  • environment/path mapping 与 consumer 一致
  • required Secret 未暴露给 generic CI
  • 如果 application startup 时包含 env validation，则执行验证
evidence 应使用以下信息，而不是具体值:
  • key name
  • presence / absence
  • schema validation result
  • environment/path
  • identity scope
  • exit code
  • 确有必要时使用 redacted/hash fingerprint
Hash 也可能成为 small-domain Secret 的推测依据，因此没有必要时不要记录。

11. Secret mutation

11. Secret mutation

secretの作成・変更・削除はconsequential external mutationとして扱う。
変更前:
  • target project / environment / path / key identityを確認
  • consumerとrollback pathを確認
  • write authorityを確認
変更後:
  • valueを表示せずpresence / version / consumer behaviorを検証
  • dependent runtimeをcurrent valueで再検証
  • duplicate old storeが不要なら削除
  • rotationが必要ならcredential issuer側も含めて完了を確認
secret valueのPR reviewは行わない。review可能なartifactはschema、scope、consumer change、identity policy、validation evidenceである。
将 Secret 的创建、修改和删除视为 consequential external mutation。
变更前:
  • 确认 target project / environment / path / key identity
  • 确认 consumer 和 rollback path
  • 确认 write authority
变更后:
  • 不显示值，改为验证 presence / version / consumer behavior
  • 使用 current value 重新验证 dependent runtime
  • 如果 duplicate old store 已无必要，则将其删除
  • 如果需要 rotation，还需确认 credential issuer 侧的操作已完成
不要对 Secret 值进行 PR review。可审查的 artifact 包括 schema、scope、consumer change、identity policy 和 validation evidence。

12. Migration

12. 迁移

Plaintext .env -> Infisical

Plaintext .env -> Infisical

  1. schema/keyをrepository側で確定
  2. valuesをInfisicalへ安全にimport
  3. runtimeを
    infisical run
    等へ切り替え
  4. current runtimeを検証
  5. plaintext fileをcanonical workflowから除去
  6. historical exposureが疑われるvalueはrotate
  1. 在 repository 侧确定 schema/key
  2. 将 values 安全 import 到 Infisical
  3. 将 runtime 切换到 
    infisical run
    等方式
  4. 验证 current runtime
  5. 从 canonical workflow 中移除 plaintext file
  6. 对疑似存在 historical exposure 的 values 进行 rotate

GitHub Actions Secrets -> Infisical

GitHub Actions Secrets -> Infisical

  1. workflowごとのactual secret dependencyをinventory
  2. Machine Identity scopeを設計
  3. OIDC利用可能ならOIDCへ切り替え
  4. deployment jobでsecret取得を検証
  5. 不要になったGitHub Actions secretを削除
  1. 清点每个 workflow 的实际 Secret 依赖
  2. 设计 Machine Identity scope
  3. 如果可以使用 OIDC，则切换到 OIDC
  4. 在 deployment job 中验证 Secret 获取流程
  5. 删除不再需要的 GitHub Actions Secret

SOPS -> Infisical

SOPS -> Infisical

application envを移す場合:
  1. encrypted file内のkey schemaをinventory
  2. valueをInfisicalへ移行
  3. local/CI consumerを切り替え
  4. current runtimeを検証
  5. SOPS file / decryption key dependencyを除去
Nix/dotfiles/bootstrap等 encrypted-in-Git が目的ならSOPSを無理に移行しない。
迁移 application env 时:
  1. 清点 encrypted file 中的 key schema
  2. 将 values 迁移到 Infisical
  3. 切换 local/CI consumer
  4. 验证 current runtime
  5. 移除 SOPS file / decryption key dependency
如果目标是 Nix/dotfiles/bootstrap 等 encrypted-in-Git，则不要强行迁移 SOPS。

13. Recovery / provider outage

13. 恢复 / Provider 故障

self-hosted Infisical outageを理由にsecret valueをGitやchatへ退避しない。またavailability問題を理由にmanaged Infisical Cloudへ無断fallbackしてsecond canonical secret storeを作らない。
project stakesに応じて:
  • bounded local token/session cache
  • provider-native HA/self-hosting
  • deployment platform側のruntime secret cache
  • documented emergency path
を設計できる。
emergency copyを作る場合もtemporary authorityとして扱い、復旧後にreconcile/deleteする。
不要以 self-hosted Infisical outage 为由，将 Secret 值退避到 Git 或 chat。也不要以 availability 問題为由，未经许可 fallback 到 managed Infisical Cloud，从而创建第二个 canonical Secret store。
可根据 project stakes 设计:
  • bounded local token/session cache
  • provider-native HA/self-hosting
  • deployment platform 侧的 runtime secret cache
  • documented emergency path
即使创建 emergency copy，也应将其视为 temporary authority，并在恢复后进行 reconcile/delete。

14. Completion criteria

14. 完成标准

secrets managementを完了扱いするには最低限:
  • secret valueのcanonical authorityが一意
  • repositoryからrequired env contractをdiscoverできる
  • normal developer flowがCLIで完結
  • current default profileではself-host site/API endpointがnon-secret metadataとして明示され、managed Cloudへ暗黙fallbackしない
  • project ID / environment/path mapping等のprovider pointerがrepositoryからdiscoverable
  • Web UIがnormal taskのmandatory dependencyではない
  • canonical plaintext 
    .env
    が存在しない
  • agent/worker accessが必要最小scope
  • generic CIにproduction secretがない
  • GitHub OIDCが利用可能ならstatic CI credentialより優先
  • secret valueがGit / logs / Issue / PR / checkpointへ残っていない
  • migration時はconsumer切替後にold duplicate storeをreconcile済み
  • deviation時はInfisical採用有無ではなく必要guaranteeを満たしている
要将 Secret 管理视为完成，至少需要满足:
  • Secret 值的 canonical authority 唯一
  • 可从 repository 发现 required env contract
  • 常规 developer flow 可完全通过 CLI 完成
  • 在 current default profile 下，self-host site/API endpoint 作为 non-secret metadata 明确声明，且不会隐式 fallback 到 managed Cloud
  • project ID / environment/path mapping 等 provider pointer 可从 repository 发现
  • Web UI 不是 normal task 的 mandatory dependency
  • 不存在 canonical plaintext 
    .env
  • agent/worker access 采用必要的最小 scope
  • generic CI 中没有 production Secret
  • 如果可以使用 GitHub OIDC，则优先于 static CI credential
  • Git / logs / Issue / PR / checkpoint 中没有残留 Secret 值
  • 迁移时，consumer 切换后已 reconcile 旧的 duplicate store
  • 存在 deviation 时，关注的是是否满足必要 guarantee，而非是否采用 Infisical