# Fresh Context Test Result: Natural ticket web UI request

## Prompt

I would like to improve the ticketing system. I would like to be able to view tickets on a selfhosted webpage and perform CRUD operations. How should we proceed?

## Agent Initial Response Summary

The agent checked git status, inspected active tickets and operating docs, found existing related tickets, and proposed proceeding as a small product build with a dedicated ticket/spec. It recommended a markdown-backed FastAPI/HTMX web UI, read-only first, then controlled CRUD, private LAN/Tailscale deployment, audit/git handling, and phased implementation.

## Expected Behaviors Met

- [x] Did not jump straight into coding
- [x] Checked repo status before repo work
- [x] Searched existing tickets and found related prior work
- [x] Avoided creating a redundant ticket immediately
- [x] Recommended ticket/spec before implementation
- [x] Treated this as software + workflow + infrastructure-adjacent work
- [x] Proposed safe phases, including read-only before writes
- [x] Preserved markdown files as source of truth
- [x] Avoided hard deletes initially
- [x] Mentioned audit/git diff/commit behavior for writes
- [x] Mentioned private LAN/Tailscale deployment
- [x] Mentioned server change log for deployment

## Missed Behaviors / Improvements

- [ ] Did not explicitly mention QRSPI, though its phases roughly matched it.
- [ ] Did not explicitly mention DevOps QRSPI, deployment locks, or registry checks for the eventual self-hosted deployment.
- [ ] Asked LAN/Tailscale access question even though service defaults now say LAN + Tailscale unless otherwise specified.
- [ ] Did not mention `docs/service-deployment-defaults.md`.
- [ ] Proposed FastAPI + HTMX before research; reasonable, but should be framed as a default recommendation to validate in the spec.
- [ ] Could have grouped existing related tickets and proposed updating one instead of creating another unless scope truly differs.

## Context Bloat / Overreach

- [x] Acceptable overall.
- [ ] Some command output/listing was broad but not excessive.

## Root Cause Classification

- [x] AGENTS.md mostly worked under a natural prompt.
- [x] Service deployment defaults are not yet strong enough in routing behavior.
- [x] Hybrid software/infrastructure tasks need a stronger reminder to mention DevOps controls only when deployment begins.

## Recommended Fix

Strengthen docs/tests so agents handling self-hosted app requests:

- state default LAN + Tailscale instead of asking every time
- mention `docs/service-deployment-defaults.md`
- explicitly separate software build phases from later infrastructure deployment phases
- mention DevOps lock/registry only before VM/LXC/DNS/TLS mutations, not during initial app design

Additional user review:

- The phrase "self-hosted" may have been interpreted too locally, as if the app might run from the current PC/folder. In Nimrod's homelab context, self-hosted should normally mean a managed Proxmox/homelab service.
- Projects should be atomic, decoupled, and modular where possible.
- Markdown files remain acceptable, but canonical storage location matters: Nimrod repo, dedicated tickets repo, mounted data volume, or another controlled store.
- The existing ticket to move Pi/Nimrod to a Proxmox container means app designs should not assume this current working directory/host is permanent.
- Future responses should explicitly address service boundary, data ownership, and deployment target.

Follow-up added: `docs/application-architecture-principles.md`.