Add Support for Optional Descriptions for Secrets

[fizahkhalid]

Summary

Currently, once a secret is created, its value cannot be viewed again for security reasons. While this is expected behavior, it creates a usability problem when returning to a project later and forgetting the intended format or expected structure of a secret (e.g., whether a URL ends with a slash or what prefix an API key should include). Without the ability to view or annotate a secret, developers must rely on memory or recreate the secret entirely.

Adding support for descriptions would solve this problem without compromising security.

Problem

When working with environment secrets, developers often need to remember details about the format, purpose, or usage of each variable. Since the actual value cannot be revealed later, there is no way to recall things like:

• Whether the value must follow a specific format
• Whether an API key requires a prefix such as "Bearer "
• Which part of the codebase relies on this secret
• What type of data the variable represents

This creates friction when revisiting a project after days or weeks, especially when maintaining many secrets.

Proposed Solution

Allow optional descriptions when creating or editing secrets. The description would not store the secret value itself, but would allow developers to document:

• Expected value format
• Purpose of the secret
• Example usage or example format
• Where it is used in the project

This would significantly improve maintainability without compromising security.

Example

Name: API_URL
Description: Base URL for internal API. Do NOT include trailing slash. Example format: https://api.example.com
Value: ************

Name: AUTH_TOKEN
Description: Token used for server-to-server communication. Must be prefixed with "Bearer ".
Value: ************