Added a simple web UI to setup the .env file to allow easy configuration of the kb-server

[christoaluckal]

Summary

PR for #7

• Added an initial admin UI at /admin for kb-server with setup, configuration, and operational visibility.
• Added backend admin routes and services for config/state aggregation and local .env updates.
• Added write-only handling for KB_API_KEY and GITHUB_TOKEN, while preserving process environment variable precedence.
• Added browser admin login flow using KB_API_KEY plus an HTTP-only cookie for /admin.
• Documented the admin UI, first-time setup flow, secret-handling model, and the new API/security/reliability semantics.
• Logged the broader admin UI rollout plan in docs and kb-server/AGENTS.md.

Why it changed:

• kb-server setup and operations were too dependent on manual .env editing, vault/repo inspection, and API/log knowledge.
• This adds a single admin surface for management and monitoring without turning the system into a note-editing UI or bypassing the
  existing PR-based content approval model.

Context System Checklist

• I updated docs when behavior/semantics changed.
• If API behavior changed, I updated related product/spec docs.
• If reliability/security assumptions changed, I updated runbooks/topical docs.
• I verified generated artifacts are up to date (python3 scripts/generate_context_artifacts.py).
• I ran docs lint checks (python3 scripts/docs_lint.py).

Docs Impact

• Docs impact present in this PR

If no docs impact, explain why:

Test Plan

• Unit tests
• Integration/manual test

Unit tests:

• cd kb-server && ./.venv/bin/python -m pytest tests/test_admin.py tests/test_config.py

Integration/manual test:

• Open /admin
• Verify config and runtime state load
• Verify /admin redirects to /admin/login when KB_API_KEY is set
• Verify saving config updates kb-server/.env
• Verify readiness, vault, database, Git, and PR status render in the admin UI

How to run

• Create a repo that will serve as the vault. flight-deck-notes in this example

• Run the steps inside kb-server/README.MD. The .env file should atleast contain VAULT_PATH and DATABASE_URL

• Start the uvicorn app

• Go to http://127.0.0.1:8000/admin, it should not require any key. Change GITHUB_REPO to the proper owner/repo format of the vault. Update KB_API_KEY and GITHUB_TOKEN fields if the server doesn't start with it.

• The form should update and say saved. Restart the server and it should prompt you for the password

• Run the autosaver with the relevant keys exported
• Update your vault. Changes should be automatically synced

- The server UI should also tell you the SHA of the change

[yashturkar]

Can you change the admin auth to use username+password credentials?

[yashturkar]

Also, can we have the API generation in the web-ui? We're moving to API based on user identity #8

[christoaluckal]

What is the mechanism that generates the API key? There's a server based generation but I'm not sure what that means. Currently KB_API_KEY is manually generated, does the functionality require that a user generates an API key via a username and password which is stored as a hash on another dedicated DB which then is validated before running kb-server updates?

[yashturkar]

What is the mechanism that generates the API key? There's a server based generation but I'm not sure what that means. Currently KB_API_KEY is manually generated, does the functionality require that a user generates an API key via a username and password which is stored as a hash on another dedicated DB which then is validated before running kb-server updates?

This has the key generation (its a hash) #8
Yes lets store the username password as a hash in a DB - just use the KB server DB we already have

[yashturkar]

We should use a friendlier interface for these