docs: comprehensive ecosystem documentation for 360Magicians / MBTQ#4
Conversation
…, pinksync, mbtquniverse
PR Summary by QodoDocs: consolidate 360Magicians/MBTQ ecosystem guides and expand OpenAPI spec
AI Description
Diagram
High-Level Assessment
Files changed (30)
|
Code Review by Qodo
1. Invalid auth header docs
|
| ## Authentication | ||
|
|
||
| Obtain a token from [DeafAUTH](https://deafauth.mbtq.dev/docs) and pass it as a ****** | ||
|
|
||
| ``` | ||
| Authorization: ****** | ||
| ``` |
There was a problem hiding this comment.
1. Invalid auth header docs 🐞 Bug ≡ Correctness
The OpenAPI description and multiple docs instruct clients to send Authorization: ******, which does not match the declared scheme: bearer DeafAUTH security scheme and will lead to invalid requests when copied. The same placeholder also creates effectively blank/misleading auth sections (e.g., empty headings) in rendered Markdown docs.
Agent Prompt
## Issue description
Auth examples are currently shown as `******`, which omits the required Bearer token format and renders poorly in Markdown. This conflicts with the OpenAPI `deafauth` security scheme (`scheme: bearer`) and will cause users to copy/paste invalid headers.
## Issue Context
The OpenAPI spec defines DeafAUTH as a bearer token scheme, but the description and docs show `Authorization: ******` instead of `Authorization: Bearer <token>`.
## Fix Focus Areas
- openapi/openapi.yaml[25-31]
- openapi/openapi.yaml[397-403]
- docs/README.md[103-114]
- docs/projects/deafauth.md[20-28]
## Suggested fix
- Replace `******` placeholders with explicit, copy/paste-safe examples:
- `Authorization: Bearer <DEAFAUTH_TOKEN>`
- In curl: `-H "Authorization: Bearer $DEAFAUTH_TOKEN"`
- Avoid unescaped asterisks in prose/headings; use `<...>` placeholders or backticks.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| AI_MODEL_OVERRIDE=llama3 # use local Ollama instead of OpenAI/Gemini | ||
| HF_TOKEN=hf_... # HuggingFace token for serverless inference | ||
| OPENAI_API_KEY=sk-... | ||
| ANTHROPIC_API_KEY=sk-ant-... | ||
| GOOGLE_AI_API_KEY=AIza... | ||
| GROQ_API_KEY=gsk_... |
There was a problem hiding this comment.
2. Secret-like env placeholders 🐞 Bug ⛨ Security
docs/ai-model-manifest.md includes example env vars with real credential prefixes (e.g., sk-..., AIza...), which can be mistaken for real secrets and may trip simplistic secret-scanning or compliance checks. These should be replaced with non-secret-pattern placeholders (e.g., <OPENAI_API_KEY>).
Agent Prompt
## Issue description
The docs include env var examples that match common real API key prefixes (`sk-`, `sk-ant-`, `AIza`, `gsk_`). Even though they contain `...`, they can be confused with actual secrets and may trigger basic secret scanners.
## Issue Context
These values appear in a `.env` example in documentation.
## Fix Focus Areas
- docs/ai-model-manifest.md[239-248]
## Suggested fix
Replace secret-looking samples with safer placeholders that do not match real key formats, e.g.:
- `OPENAI_API_KEY=<OPENAI_API_KEY>`
- `ANTHROPIC_API_KEY=<ANTHROPIC_API_KEY>`
- `GOOGLE_AI_API_KEY=<GOOGLE_AI_API_KEY>`
- `GROQ_API_KEY=<GROQ_API_KEY>`
Optionally add a one-liner: "Never paste real keys into docs; use placeholders."
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Summary
Consolidates all documentation added across multiple sessions into a single PR covering the full 360Magicians / MBTQ ecosystem.
New Docs
docs/git-workflow.mddocs/helm.mddocs/providers.mddocs/environments.md.envvar reference, secrets management rules, promotion checklistdocs/package-managers.md/serverdirectory layoutdocs/triggers-webhooks.mddocs/pipeline-handoffs.mddocs/copilot-bots.mddocs/ai-model-manifest.mddocs/ai-inference.mdopenapi/openapi.yamlIndex Updates
docs/README.md— split into Ecosystem Guides + Project Docs sections; linked all new filesREADME.md(root) — same split + new entries linkeddocs/infrastructure.md— minor additions