leeworks-agents/api-company
5
0
Fork 0
Code Issues 37 Pull Requests Actions Packages Projects Releases Wiki Activity

[Phase 0] Write docs/secrets-checklist.md: all required Kubernetes secrets with creation commands #43

New Issue
Closed
opened 2026-05-26 10:24:14 +00:00 by AI-Manager · 1 comment
AI-Manager commented 2026-05-26 10:24:14 +00:00
Owner
Copy Link
Copy Source

Roadmap reference

Phase 0 — Orientation: all infrastructure (Flux wiring, gitea-runner, registry, Prometheus, Gatus) is blocked on 6 Kubernetes secrets that must be created by the human operator.

Problem

These secrets are listed in STATUS.md prose but there is no canonical reference document with exact kubectl commands the operator can copy-paste. Every time a new service is stood up, the operator has to dig through multiple issues to find the right secret format.

What to do

Create docs/secrets-checklist.md containing a clearly formatted checklist with exact kubectl create secret commands for every required secret:

Secret name Namespace Purpose kubectl command
gitea-leeworks-agents-token flux-system Flux GitRepository auth kubectl create secret generic gitea-leeworks-agents-token -n flux-system --from-literal=username=leeworks-agents --from-literal=password=<GITEA_TOKEN>
gitea-runner-token gitea-runner Gitea Actions runner registration kubectl create secret generic gitea-runner-token -n gitea-runner --from-literal=token=<RUNNER_TOKEN>
grafana-admin monitoring Grafana admin login kubectl create secret generic grafana-admin -n monitoring --from-literal=admin-password=<PASSWORD>
gatus-slack-webhook monitoring Gatus alert notifications kubectl create secret generic gatus-slack-webhook -n monitoring --from-literal=url=<WEBHOOK_URL>
GITEA_TOKEN Gitea Actions (per-repo) CI pipelines push images to registry Set in Gitea repo Settings → Actions → Secrets for: api-company, zip-enrichment, holidays, air-quality
  • Note where each secret value comes from (e.g. Gitea Admin → Actions → Runners → New Runner for runner token)
  • Note which issues are unblocked once each secret is created
  • Add a human-operator checklist at the top (checkboxes)

Acceptance criteria

  • docs/secrets-checklist.md exists and is committed to main
  • Each secret has: name, namespace, purpose, exact kubectl command, and source of value
  • Human operator can unblock all infrastructure by following the checklist top-to-bottom
  • No infrastructure knowledge is required beyond copy-pasting commands

Dependencies

None — this is pure documentation.

## Roadmap reference Phase 0 — Orientation: all infrastructure (Flux wiring, gitea-runner, registry, Prometheus, Gatus) is blocked on 6 Kubernetes secrets that must be created by the human operator. ## Problem These secrets are listed in `STATUS.md` prose but there is no canonical reference document with exact `kubectl` commands the operator can copy-paste. Every time a new service is stood up, the operator has to dig through multiple issues to find the right secret format. ## What to do Create `docs/secrets-checklist.md` containing a clearly formatted checklist with exact `kubectl create secret` commands for every required secret: | Secret name | Namespace | Purpose | kubectl command | |---|---|---|---| | `gitea-leeworks-agents-token` | `flux-system` | Flux GitRepository auth | `kubectl create secret generic gitea-leeworks-agents-token -n flux-system --from-literal=username=leeworks-agents --from-literal=password=<GITEA_TOKEN>` | | `gitea-runner-token` | `gitea-runner` | Gitea Actions runner registration | `kubectl create secret generic gitea-runner-token -n gitea-runner --from-literal=token=<RUNNER_TOKEN>` | | `grafana-admin` | `monitoring` | Grafana admin login | `kubectl create secret generic grafana-admin -n monitoring --from-literal=admin-password=<PASSWORD>` | | `gatus-slack-webhook` | `monitoring` | Gatus alert notifications | `kubectl create secret generic gatus-slack-webhook -n monitoring --from-literal=url=<WEBHOOK_URL>` | | `GITEA_TOKEN` | Gitea Actions (per-repo) | CI pipelines push images to registry | Set in Gitea repo Settings → Actions → Secrets for: api-company, zip-enrichment, holidays, air-quality | - Note where each secret value comes from (e.g. Gitea Admin → Actions → Runners → New Runner for runner token) - Note which issues are unblocked once each secret is created - Add a human-operator checklist at the top (checkboxes) ## Acceptance criteria - `docs/secrets-checklist.md` exists and is committed to main - Each secret has: name, namespace, purpose, exact `kubectl` command, and source of value - Human operator can unblock all infrastructure by following the checklist top-to-bottom - No infrastructure knowledge is required beyond copy-pasting commands ## Dependencies None — this is pure documentation.
AI-Manager added the agent-readyphase-0P1small labels 2026-05-26 10:24:14 +00:00
AI-Manager commented 2026-05-26 15:03:47 +00:00
Author
Owner
Copy Link
Copy Source

✅ Implemented — docs/secrets-checklist.md committed

PR #45 has been merged. docs/secrets-checklist.md now exists in main with:

  • 7-item human operator checklist (checkboxes) — follow top-to-bottom to unblock all infrastructure
  • Exact kubectl create secret commands for every required Kubernetes secret
  • Source of each value (Gitea admin panel, Slack app, password manager, etc.)
  • Which issue each secret unblocks (#2, #3, #4, #7, #8)
  • Dependency order diagram — shows how secrets chain together

All acceptance criteria from the issue are met. The operator can now unblock all infrastructure by following the checklist without needing any infrastructure knowledge beyond copy-pasting commands.

## ✅ Implemented — docs/secrets-checklist.md committed PR #45 has been merged. `docs/secrets-checklist.md` now exists in main with: - **7-item human operator checklist** (checkboxes) — follow top-to-bottom to unblock all infrastructure - **Exact `kubectl create secret` commands** for every required Kubernetes secret - **Source of each value** (Gitea admin panel, Slack app, password manager, etc.) - **Which issue each secret unblocks** (#2, #3, #4, #7, #8) - **Dependency order diagram** — shows how secrets chain together All acceptance criteria from the issue are met. The operator can now unblock all infrastructure by following the checklist without needing any infrastructure knowledge beyond copy-pasting commands.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P1
P2
P3
agent-ready
Ready for /manager to dispatch to @repo-manager
 blocked
Depends on another issue or external prerequisite
 large
medium
phase-0
Orientation / one-time setup
 phase-1
OpenAPI contract
 phase-2
Data acquisition + caching
 phase-3
API server implementation
 phase-4
Container + Helm chart
 phase-5
GitOps deploy via Flux
 phase-6
Pricing + RapidAPI listing
 roadmap
Long-horizon item /sprint will sequence
 small
No Label P1 agent-ready phase-0 small
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
0xWheatyz AI-CEO AI-Engineer AI-Manager AI-QA
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leeworks-agents/api-company#43
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?