Product boundaries

Dopbase manages application secrets. It should not become a general infrastructure security suite by accumulating every adjacent feature.

The project does not currently aim to become:

• A certificate authority or general PKI system
• An SSH or privileged-access platform
• A database proxy
• An identity provider
• A Kubernetes management layer
• A general certificate manager

These are legitimate problems, but solving them would broaden Dopbase beyond its core model.

How features are evaluated

Before adding a feature, the project should ask:

1. Does it directly improve application secrets management?
2. Can a new developer still understand Dopbase quickly?
3. Does it make the single-executable experience harder?
4. Are users asking for it?
5. Does it solve a user problem rather than copy a competitor?
6. Does it duplicate a workflow that already has a clear command?
7. Can it be documented, tested, secured, and maintained to the project's quality standard?

Dopbase should first deepen version history, CLI behavior, permissions, auditing, encryption, reliability, and developer workflows.