## TL;DR
A namespace is not restored when its workloads run but its secrets are absent: applications can start and fail at first use, or worse, fall back to defaults. Include secrets and configmaps in the restore's resource reconciliation, verify each expected secret exists by name with its keys present, without reading values aloud, and add an application smoke check that exercises a secret-dependent path before declaring recovery.

```text
agent restored a Kubernetes namespace without its secrets and declared the application recovery successful
```

## Use this when
- The job or restore fails with this symptom: agent restored a Kubernetes namespace without its secrets and declared the application recovery successful.
- You are working on an agent restoring Kubernetes namespaces with Velero or similar tooling and the failure repeats on the same target or schedule.
- You need the failing job, stage, or component isolated before changing retention or infrastructure.

## Not for this skill when
- Secrets intentionally excluded from backup for policy, which must then be re-created from the secret manager as a named restore step, not omitted silently.
- The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. List the source namespace's secrets and configmaps from the backup's inventory and compare with the restored namespace by name. Verify: the configuration gap is enumerated
2. Restore the missing secrets from the backup or re-create them from the secret manager, per the namespace's policy. Verify: secrets are present with their expected keys
3. Verify key presence and counts per secret without exposing values in logs or reports. Verify: verification respects the secrets it checks
4. Run an application probe that uses a secret, such as a database login from the app pod, as the recovery gate. Verify: recovery is proven at the application layer
5. Add secrets and configmaps to the restore reconciliation the agent performs for every namespace. Verify: the class of omission is closed

## Variant phrasings
### agent restored kubernetes namespace without secrets declared successful
The verbatim phrasing.
### namespace restore missing secrets configmaps reconciliation agent fix
The reconciliation phrasing.
### agent k8s recovery incomplete secrets smoke test database login
The smoke-test phrasing.

Compatibility: Agent restore verification for Kubernetes namespaces including secrets

## Why it happens
Kubernetes restores are selective by resource type, and secrets are commonly filtered, excluded, or handled by a separate path, so a workloads-only restore looks complete in every pod listing. The missing pieces announce themselves only when the application reaches for them, which is after the recovery has been declared.

## Edge cases / pitfalls
- Secret values must never enter agent logs or reports; names, key names, and counts carry all the verification signal needed.
- Namespaces restored frequently deserve a standing expected-resources manifest the reconciliation compares against.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0nMZtmD37jWHVieHaf7uVg