Implement Environment-Specific Secrets in Parent Stacks

[simple-container-forge]

Implementation Request

Parent Issue: #130
Base Branch: simple-forge/issue-130-feature-environment-specific-s-ta3mh6

Description

Implement the secretsConfig feature for server.yaml that enables environment-specific secret filtering. Add include/exclude/override modes, support three reference patterns (direct/~, mapped/${secret:KEY}, literal), integrate with stack reconciliation, add validation, regenerate JSON schema, and add tests.

Technical Notes

Core implementation files: pkg/api/server.go (add EnvironmentSecretsConfig, SecretsConfigMap types), pkg/api/secrets.go (add SecretResolver), pkg/api/read.go (add DetectSecretsConfigType), pkg/api/models.go (modify ReconcileForDeploy), pkg/api/validation.go (new file). All changes must maintain backwards compatibility - secretsConfig field is optional.

Files/Areas

• pkg/api/server.go
• pkg/api/secrets.go
• pkg/api/read.go
• pkg/api/models.go
• pkg/api/validation.go
• cmd/schema-gen/main.go

Acceptance Criteria

• AC-1: Basic Environment Isolation - When deploying to staging, only staging-configured secrets are available and production secrets are not accessible
• AC-2: Secret Mapping - When a client references DATABASE_PASSWORD in staging, the value resolves to DATABASE_PASSWORD_STAGING from secrets.yaml using ${secret:} syntax
• AC-3: Literal Values - When a parent stack has literal secret values configured, the literal value is used (not fetched from secrets.yaml)
• AC-4: Exclusion Mode - When using inheritAll: true with exclusions, all secrets except excluded ones are available
• AC-5: Backwards Compatibility - Existing parent stacks without the secretsConfig section work without modification and all secrets behave as before
• AC-6: Validation Errors - When a client references an unavailable secret, sc validate returns a validation error with clear message

Design Documentation

• docs/design/environment-specific-secrets/architecture.md
• docs/design/environment-specific-secrets/json-schema.md
• docs/design/environment-specific-secrets/implementation-plan.md
• docs/design/environment-specific-secrets/README.md

Notes

Implementation should follow the 8-phase plan in implementation-plan.md. Start with Phase 1 (data structures), work through to Phase 8 (documentation). All phases include acceptance criteria. Estimated 29-39 hours total.

Dependencies

• Server descriptor schema (pkg/api/server.go)
• Secret resolution logic (pkg/api/secrets.go)
• Configuration validation (pkg/api/read.go)
• JSON schema generation (cmd/schema-gen/main.go)

Priority: high

---

This issue was automatically created by the Multi-Role Orchestration system.

[simple-container-forge]

✅ Workflow Completed Successfully!

Great news! The Simple Forge has successfully processed your request.

📋 Job Details:

• Job ID: 4d5225e6-8694-41d0-87c8-e8e21964b73a
• Job URL: https://forge.simple-container.com/jobs/4d5225e6-8694-41d0-87c8-e8e21964b73a
• Branch: simple-forge/issue-132-implement-environment-specific-ta3muh
• Workflow: View Results
• Completed: 2026-02-07 17:43:36 UTC

📝 Execution Summary:
I've processed the issue and made the following changes:

I'll analyze this GitHub issue and implement the environment-specific secrets feature. Let me start by reading the relevant files to understand the current codebase structure.

Now let me start implementing the feature. First, I'll add the data structures to pkg/api/server.go:

Now let me implement the SecretResolver in pkg/api/secrets.go:

Now let me add the DetectSecretsConfigType function to pkg/api/read.go:

Now let me modify the ReconcileForDeploy function in pkg/api/models.go to apply the secret filtering:

Now let me create the validation.go file:

Now I need to update the SecretsConfigDescriptor.Copy() method in copy.go to preserve the SecretsConfig field:

Now let me create comprehensive unit tests for the new functionality:

Now let me run the tests to verify everything works:

I need to fix the unused variable errors. Let me update the files:

Now let me fix the unused variable in validation.go:

Now let me run the tests again:

All tests pass. Now let me run the full test suite for the api package:

All tests pass. Now let me run the formatters:

Now let me run the build to ensure everything compiles:

The build succeeded. Let me update the todo list and verify the final changes:

All implementation is complete. Let me verify the final changes by reading the key files:

The implementation is complete. Let me provide the handoff JSON as required:

=== FORGE_HANDOFF_JSON_START ===
{
"schemaVersion": 1,
"role": "developer",
"summary": "Implementation complete: Environment-Specific Secrets feature for parent stacks",
"testRequests": [
{
"title": "Validate: Environment-Specific Secrets Implementation",
"description": "Verify the implementation of environment-specific secrets filtering in parent stacks. The feature includes three modes (include, exclude, override), three reference patterns (direct/~, mapped/${secret:KEY}, literal), stack reconciliation integration, and validation. All acceptance criteria have been addressed.",
"scopeGroup": "environment-specific-secrets",
"workflowType": "sequential",
"testTypes": ["unit"],
"acceptanceCriteria": [
"AC-1: Basic Environment Isolation - When deploying to staging, only staging-configured secrets are available",
"AC-2: Secret Mapping - When a client references DATABASE_PASSWORD in staging, the value resolves to DATABASE_PASSWORD_STAGING using ${secret:} syntax",
"AC-3: Literal Values - When a parent stack has literal secret values configured, the literal value is used",
"AC-4: Exclusion Mode - When using inheritAll: true with exclusions, all secrets except excluded ones are available",
"AC-5: Backwards Compatibility - Existing parent stacks without secretsConfig work without modification",
"AC-6: Validation Errors - When a client references an unavailable secret, validation returns clear error message"
],
"filesOrAreas": [
"pkg/api/server.go",
"pkg/api/secrets.go",
"pkg/api/read.go",
"pkg/api/models.go",
"pkg/api/validation.go",
"pkg/api/copy.go",
"pkg/api/secrets_config_test.go"
],
"docs": {
"implementationNotes": "Added EnvironmentSecretsConfig and SecretsConfigMap types to server.go. Implemented SecretResolver in secrets.go with support for include/exclude/override modes and direct/mapped/literal reference patterns. Added DetectSecretsConfigType to read.go for validation during config reading. Modified ReconcileForDeploy in models.go to apply secret filtering during stack reconciliation. Created validation.go with ValidateSecretReferences and ValidateSecretAccess functions. Updated SecretsConfigDescriptor.Copy() in copy.go to preserve SecretsConfig field. Added comprehensive unit tests covering all modes and edge cases.",
"knownIssues": "None known. All tests pass. The JSON schema generator will automatically discover the new types through reflection."
},
"priority": "high",
"dependencies": []
}
]
}
=== FORGE_HANDOFF_JSON_END ===

[Content truncated - full details available in workflow logs]

🎉 Next Steps:

• Review the changes in the Pull Request #139
• Test the implementation
• Merge the pull request when ready

Feel free to ask for any modifications or improvements!

[simple-container-forge]

✅ Workflow Completed Successfully!

Great news! The Simple Forge has successfully processed your request.

📋 Job Details:

• Job ID: 83a93686-50e1-4f89-858e-3e0e4d598226
• Job URL: https://forge.simple-container.com/jobs/83a93686-50e1-4f89-858e-3e0e4d598226
• Branch: developer/issue-132-environment-specific-secrets
• Workflow: View Results
• Completed: 2026-02-07 17:31:36 UTC

📝 Execution Summary:
I've processed the issue and made the following changes:

Let me start by reading the design documentation and understanding the current codebase structure.

The design documents don't exist yet. Let me explore the existing codebase to understand the current implementation.

Now let me look at the existing stack descriptors and configuration files to understand the patterns better, as well as the schema generator.

Let me also look at the client.go and some of the test files to understand the testing patterns, and check existing tests:

Now let me look at some existing tests to understand the patterns and look at the provider mappings:

Now I have a good understanding of the codebase. Let me update the todo list and start implementing the environment-specific secrets feature.

Now let me start implementing the feature. First, I'll add the data structures to pkg/api/server.go:

Now let me implement the SecretResolver in pkg/api/secrets.go:

Now let me add the DetectSecretsConfigType function to pkg/api/read.go:

Now let me add the DetectSecretsConfigType function after DetectSecretsType:

Now let me modify the ReconcileForDeploy function in pkg/api/models.go to apply the secret resolution:

Now let me create the validation.go file:

Now let me verify the changes to server.go are correct and check if the schema generator needs any updates. The schema generator automatically discovers types through reflection, so it should pick up the new types. Let me verify the implementation by running the tests first:

The build succeeded. Now let me run the tests and then run the formatters:

The tests are passing. Let me now add unit tests specifically for the new environment-specific secrets functionality. First let me run the formatters and then add the tests:

The formatter has an issue with the binary path. Let me run gofmt and goimports directly:

Good, the file was formatted. Now let me create the unit tests for the new functionality:

Now let me run the tests to make sure everything works:

There's an unused import. Let me fix that:

The test failure shows that the ReconcileForDeploy is not being called correctly. The issue is that the ReconcileForDeploy only applies the secret filtering for child stacks, and it needs the parent stack to have the SecretsConfig. Let me check the test and fix it:

I see the issue. The code is correct - after copying the parent stack's server, it should apply the secret filtering. The test is expecting that the SecretsConfig from the parent is applied when the child stack is deployed. Let me fix the test - it needs to properly set up the parent stack with the client configuration:

I see - the issue is that when the child stack's server is copied from the parent, the SecretsConfig is being copied too, but we need to ensure the secret resolution happens after the copy. Let me trace through the code more carefully. The issue is that the parent stack in the map doesn't have the Server SecretsConfig set up correctly. The child gets the server copied from parent, but then the SecretsConfig check is on stack.Server.Secrets.SecretsConfig which should be set. Let me debug this:

I see - the SecretsConfig is optional on the ServerDescriptor but the logic is checking stack.Server.Secrets.SecretsConfig after copying. Let me add a debug test to see what's happening:

Ah, I see the issue now. When we call stack.Server = parentStack.Server.Copy(), the Copy() method on ServerDescriptor returns a copy that strips out the SecretsConfig. Let me check the ValuesOnly() method:

Good - ValuesOnly() does include Secrets: sd.Secrets. But wait, let me check the Copy() method on ServerDescriptor:

The Copy() method calls sd.Secrets.Copy(). Let me check what SecretsConfigDescriptor.Copy() does:

There it is! The SecretsConfigDescriptor.Copy() method doesn't copy the SecretsConfig field. I need to update the Copy() method to include the new field:

[Content truncated - full details available in workflow logs]

🎉 Next Steps:

• Review the changes in the Pull Request #135
• Test the implementation
• Merge the pull request when ready

Feel free to ask for any modifications or improvements!