# Ticket: Web frontend for Pi operations

## Metadata
- Type: Ticket
- Status: Planned
- Project: Pi / Nimrod
- Created: 2026-05-17
- Updated: 2026-05-17
- Priority: Medium

## Goal

Design and build a web-based frontend for Pi/Nimrod operations, including tickets, specs, monitoring, status, and operational workflows.

## Why

The repo-based workflow is powerful but not always convenient. A web UI would make Pi's work easier to inspect, manage, and operate, especially for tickets/specs, service health, queued requests, change logs, and monitoring dashboards.

## Scope

Included:
- Define requirements for a local/private web frontend.
- Display tickets, specs, backlog, active work, and done/archive status.
- Display system/service status and monitoring summaries.
- Display queued Nextcloud Talk Pi requests.
- Link to relevant docs, runbooks, and change logs.
- Support safe editing or creation of tickets/specs, if approved.
- Define authentication and network exposure constraints.
- Prefer read-only MVP before adding write actions.

Not included:
- Public internet exposure without separate security review.
- Replacing the git/repo source of truth in v1.
- Unreviewed destructive operational actions from the UI.

## Acceptance Criteria

This ticket is done when:
- [ ] A frontend spec exists.
- [ ] Security/exposure model is documented.
- [ ] MVP technology choice is selected.
- [ ] Read-only prototype can show tickets/specs/backlog/status.
- [ ] Monitoring/status sources are defined.
- [ ] Write actions, if any, require clear confirmation and are logged.
- [ ] Deployment/runbook exists.

## Questions

- Should this be part of Nextcloud, a separate local web app, or a Pi extension/TUI-adjacent dashboard?
- Should the first frontend be read-only?
- What authentication should be used: Nextcloud SSO, basic auth behind LAN/Tailscale, or app-local login?
- Which monitoring data matters first: service health, ticket counts, queued requests, server status, or change logs?
- Should it edit Markdown files directly or generate PR-style patches for review?

## Plan / Next Actions

- [ ] Draft a web frontend spec.
- [ ] Inventory data sources: tickets, specs, tasks, docs, service status, Nextcloud request queue.
- [ ] Choose MVP architecture and deployment target.
- [ ] Prototype read-only ticket/spec/status dashboard.
- [ ] Add authenticated write workflows only after reviewing safety model.

## 2026-05-17 Spec Advancement

Confidence level: high that a read-only web UI is the safe MVP; medium for technology choice; low for write workflows until auth/threat model is done.

Decisions now stable:
- The repo remains source of truth in v1.
- The first UI should be private/LAN/Tailscale-only and read-only.
- Write actions should come later and produce reviewable Markdown patches or queued changes, not silent edits.

Proposed MVP spec:
- Read-only dashboard showing tickets by status/project, specs, tasks/now, backlog, server change log, service health, and queued Pi requests.
- Data source: parse Markdown files from this repo plus optional controlled SSH status checks.
- Deployment: local/private service, not public internet.
- Security: authentication required before any write workflow; no destructive controls in v1.

Updated next actions:
- [ ] Create a frontend spec under `projects/pi-web-frontend/spec.md`.
- [ ] Inventory Markdown data model for tickets/specs/tasks.
- [ ] Choose MVP stack only after spec: simple Python/FastAPI, static site generator, or Nextcloud app are candidates.
- [ ] Prototype read-only dashboard before implementing edits.

## Notes

- User requested this as a future Pi upgrade on 2026-05-17.
- This should probably follow the feedback system and controlled Pi request workflow, because those define important UI data sources.