first version of the knowledge base :)

10 - Projects/projects-overview.md

@@ -0,0 +1,62 @@
+---
+title: Projects Overview
+description: Public overview of the current Hidden Den project landscape and how those projects relate to the wider ecosystem
+tags:
+  - projects
+  - overview
+  - hidden-den
+category: projects
+created: 2026-03-14
+updated: 2026-03-14
+---
+
+# Projects Overview
+
+## Summary
+
+The Hidden Den ecosystem includes a small set of public projects that reflect its broader themes: self-hosting, operational clarity, community tooling, and maintainable personal infrastructure.
+
+## Why it matters
+
+Project documentation helps readers understand where Den Vault fits. It connects the knowledge base to the practical tools and experiments that motivate many of the architectural and workflow notes documented elsewhere in the repository.
+
+## Core concepts
+
+- Stable tools are documented differently from in-progress experiments
+- Project status should be visible so readers know what is operational versus exploratory
+- Projects should be framed by what problem they solve, not only by their implementation details
+
+## Practical usage
+
+Publicly visible projects in the Hidden Den ecosystem currently include:
+
+- `GuardDen`: security and moderation tooling for community operations; shown publicly as stable
+- `openrabbit`: an open-source tool with an accessibility and community-development focus; shown publicly as stable
+- `DevDen`: a development environment concept for the broader Den ecosystem; shown publicly as concept-stage
+- `loyal_companion`: a companion bot project; shown publicly as work in progress
+
+These projects suggest several documentation priorities for Den Vault:
+
+- Self-hosted Git and forge workflows
+- Bot and automation deployment patterns
+- Security and moderation tooling architecture
+- Durable development environments for small independent platforms
+
+## Best practices
+
+- Keep project descriptions short, public, and non-sensitive
+- Record project maturity so readers understand whether a document is a reference, an experiment, or a roadmap item
+- Link project docs to related tool, guide, and architecture pages when those pages exist
+- Avoid over-documenting early concepts before the architecture stabilizes
+
+## Pitfalls
+
+- Treating project listings as a substitute for real technical documentation
+- Publishing internal implementation details before they are safe for public release
+- Letting project status drift out of date
+- Mixing aspirational ideas with stable operating guidance without labeling the difference
+
+## References
+
+- [Gitea Documentation](https://docs.gitea.com/)
+- [Write the Docs: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/)