* fix(agents): avoid injecting memory file twice on case-insensitive mounts
On case-insensitive file systems mounted into Docker from macOS, both
MEMORY.md and memory.md pass fs.access() even when they are the same
underlying file. The previous dedup via fs.realpath() failed in this
scenario because realpath does not normalise case through the Docker
mount layer, so both paths were treated as distinct entries and the
same content was injected into the bootstrap context twice, wasting
tokens.
Fix by replacing the collect-then-dedup approach with an early-exit:
try MEMORY.md first; fall back to memory.md only when MEMORY.md is
absent. This makes the function return at most one entry regardless
of filesystem case-sensitivity.
* docs: clarify singular memory bootstrap fallback
* fix: note memory bootstrap fallback docs and changelog (#26054) (thanks @Lanfei)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
## Summary
- Problem: `src/secrets/target-registry.test.ts` fails on latest `main` because the runtime registry includes Feishu `encryptKey` paths that the docs matrix and surface reference omit.
- Why it matters: the docs/runtime sync guard currently blocks prep and merge work for unrelated PRs, including `#25558`.
- What changed: regenerated the secretref credential matrix and updated the surface reference to include both Feishu `encryptKey` paths.
- What did NOT change (scope boundary): no runtime registry behavior, config semantics, or channel handling changed.
## Change Type (select all)
- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [x] Docs
- [ ] Security hardening
- [ ] Chore/infra
## Scope (select all touched areas)
- [ ] Gateway / orchestration
- [ ] Skills / tool execution
- [ ] Auth / tokens
- [ ] Memory / storage
- [x] Integrations
- [ ] API / contracts
- [ ] UI / DX
- [ ] CI/CD / infra
## Linked Issue/PR
- Closes #
- Related #25558
## User-visible / Behavior Changes
None.
## Security Impact (required)
- New permissions/capabilities? `No`
- Secrets/tokens handling changed? `No`
- New/changed network calls? `No`
- Command/tool execution surface changed? `No`
- Data access scope changed? `No`
- If any `Yes`, explain risk + mitigation:
## Repro + Verification
### Environment
- OS: macOS
- Runtime/container: Node.js repo checkout
- Model/provider: N/A
- Integration/channel (if any): Feishu docs/runtime registry sync
- Relevant config (redacted): none
### Steps
1. Check out latest `main` before this change.
2. Run `./node_modules/.bin/vitest run --config vitest.unit.config.ts src/secrets/target-registry.test.ts`.
3. Apply this docs-only sync change and rerun the same command.
### Expected
- The target registry stays in sync with the generated docs matrix and the test passes.
### Actual
- Before this change, the test failed because `channels.feishu.encryptKey` and `channels.feishu.accounts.*.encryptKey` were missing from the docs artifacts.
## Evidence
Attach at least one:
- [x] Failing test/log before + passing after
- [ ] Trace/log snippets
- [ ] Screenshot/recording
- [ ] Perf numbers (if relevant)
## Human Verification (required)
What you personally verified (not just CI), and how:
- Verified scenarios: confirmed the failure on plain latest `main`, applied only these docs entries in a clean bootstrapped worktree, and reran `./node_modules/.bin/vitest run --config vitest.unit.config.ts src/secrets/target-registry.test.ts` to green.
- Edge cases checked: verified both top-level Feishu `encryptKey` and account-scoped `encryptKey` paths are present in the matrix and surface reference.
- What you did **not** verify: full repo test suite and CI beyond the targeted regression.
## Review Conversations
- [x] I replied to or resolved every bot review conversation I addressed in this PR.
- [x] I left unresolved only the conversations that still need reviewer or maintainer judgment.
If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.
## Compatibility / Migration
- Backward compatible? `Yes`
- Config/env changes? `No`
- Migration needed? `No`
- If yes, exact upgrade steps:
## Failure Recovery (if this breaks)
- How to disable/revert this change quickly: revert this commit.
- Files/config to restore: `docs/reference/secretref-user-supplied-credentials-matrix.json` and `docs/reference/secretref-credential-surface.md`
- Known bad symptoms reviewers should watch for: the target-registry docs sync test failing again for missing Feishu `encryptKey` entries.
## Risks and Mitigations
- Risk: the markdown surface reference could drift from the generated matrix again in a later credential-shape change.
- Mitigation: `src/secrets/target-registry.test.ts` continues to guard docs/runtime sync.
* add web search to onboarding flow
* remove post onboarding step (now redundant)
* post-onboarding nudge if no web search set up
* address comments
* fix test mocking
* add enabled: false assertion to the no-key test
* --skip-search cli flag
* use provider that a user has a key for
* add assertions, replace the duplicated switch blocks
* test for quickstart fast-path with existing config key
* address comments
* cover quickstart falls through to key test
* bring back key source
* normalize secret inputs instead of direct string trimming
* preserve enabled: false if it's already set
* handle missing API keys in flow
* doc updates
* hasExistingKey to detect both plaintext strings and SecretRef objects
* preserve enabled state only on the "keep current" paths
* add test for preserving
* better gate flows
* guard against invalid provider values in config
* Update src/commands/configure.wizard.ts
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
* format fix
* only mentions env var when it's actually available
* search apiKey fields now typed as SecretInput
* if no provider check if any search provider key is detectable
* handle both kimi keys
* remove .filter(Boolean)
* do not disable web_search after user enables it
* update resolveSearchProvider
* fix(onboarding): skip search key prompt in ref mode
* fix: add onboarding web search step (#34009) (thanks @kesku)
---------
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Co-authored-by: Shadow <hi@shadowing.dev>
