ServiceNow

Build a local, single-user request queue called "Deskless". This is a personal consolation build for ServiceNow, not an ITSM platform. Be honest about scope.

Stack, no substitutions:
- Next.js 15 App Router, TypeScript, Tailwind.
- SQLite via better-sqlite3, file at ./data/deskless.db, schema created on boot if missing.
- Server Actions for all mutations. No API routes unless needed.
- No auth, no accounts, no telemetry, no cloud. It runs at localhost:3000 for one person.

Data model:
- assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
- tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.
- events: id, ticket_id, at, kind (created, state_change, comment, field_change), from_value, to_value, note. Append only, never edited or deleted.

Features in scope:
- Ticket list with filters by state, type, priority, and a text search over title and body.
- New ticket form where the fields shown change by type: change tickets additionally ask for rollback_plan and planned_window, stored as JSON in an extra_fields column.
- Ticket detail page: state transition buttons, comment box, linked asset, and the full audit log rendered as a timeline.
- Assets page: create, list, and see all tickets touching an asset.
- A "Weekly" view: tickets closed in the last 7 days and anything still open past its due date.
- Export everything to a single JSON file via a button, and a CSV export of tickets.

Explicitly out of scope, do not build: SLAs, approval chains, discovery agents, email ingestion, multi-user roles, SSO, a workflow designer.

Deliver: a README with setup in three commands, a seed script that inserts 12 sample tickets and 5 assets, and one Vitest file covering that state changes always write an events row.

# AGENTS.md — Build guide for ServiceNow

## Project scope
A local ticket queue with typed request forms, state transitions, an append-only audit log, and a tiny asset table you can link tickets to.

Catalogue verdict: no. You can build a ticket tracker in an afternoon. You cannot build ServiceNow, because ServiceNow is not a ticket tracker: it is a CMDB, an approval engine, a change management workflow that auditors accept, and a discovery agent crawling every asset on a corporate network. Nobody buys it because the forms are nice, they buy it because Sarbanes-Oxley auditors and ISO reviewers already know what a ServiceNow change record looks like. The personal version of this makes no sense either, since a single human does not need a change advisory board. If you genuinely want the shape of it for yourself, build a small request queue with states and an audit log and stop there.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- Node 20+
- A browser
- Nothing else, it runs on local SQLite

## Stack and architecture
- SQLite via better-sqlite3, file at ./data/deskless.db, schema created on boot if missing.
- Data model:.
- Interface for this ITSM and enterprise workflow platform workflow: a focused ITSM and enterprise workflow platform input, review, and export interface.

## Security and data integrity
- tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.
- Validate imported records and file paths; keep user data within the storage location named in the prompt.
- State the practical limit: Automated discovery and a real CMDB that maps thousands of assets and their dependencies.

## Agent implementation rules
- Project rule, data: Data model:.
- Project rule, behavior: assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
- Project rule, recovery: tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this ITSM and enterprise workflow platform operation with sample or user-owned data: assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
- Show a concrete result or export: Export everything to a single JSON file via a button, and a CSV export of tickets.
- State the practical limit: Automated discovery and a real CMDB that maps thousands of assets and their dependencies.

## Engineering roadmap
1. Phase 1, architecture and data: SQLite via better-sqlite3, file at ./data/deskless.db, schema created on boot if missing. Data model:.
2. Phase 2, implement: assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
3. Phase 3, implement: tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.
4. Phase 4, review and output: events: id, ticket_id, at, kind (created, state_change, comment, field_change), from_value, to_value, note. Append only, never edited or deleted. Export everything to a single JSON file via a button, and a CSV export of tickets.
5. Phase 5, recovery and acceptance: tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at. Verify this invariant with a saved fixture: A retry after a provider timeout must not repeat a completed external action without an explicit reconciliation step. State the practical limit: Automated discovery and a real CMDB that maps thousands of assets and their dependencies.

## Paid-product capabilities outside this build
- Automated discovery and a real CMDB that maps thousands of assets and their dependencies
- Change management and approval workflows that auditors and compliance frameworks already recognize
- Hundreds of prebuilt integrations into AD, Okta, Jira, SAP, monitoring tools and everything else in a corporate stack
- Role based access, SSO, data residency, and the enterprise security paperwork that comes with it
- An ecosystem of certified admins, partners and store apps, which is often the real reason the contract renews

## Implementation prompt
Build a local, single-user request queue called "Deskless". This is a personal consolation build for ServiceNow, not an ITSM platform. Be honest about scope.

Stack, no substitutions:
- Next.js 15 App Router, TypeScript, Tailwind.
- SQLite via better-sqlite3, file at ./data/deskless.db, schema created on boot if missing.
- Server Actions for all mutations. No API routes unless needed.
- No auth, no accounts, no telemetry, no cloud. It runs at localhost:3000 for one person.

Data model:
- assets: id, name, kind (laptop, service, subscription, account), owner_note, created_at.
- tickets: id, key (auto like REQ-0001), title, body, type (incident, request, change), priority (low, med, high), state (new, in_progress, waiting, done, cancelled), asset_id nullable, due_date nullable, created_at, updated_at.
- events: id, ticket_id, at, kind (created, state_change, comment, field_change), from_value, to_value, note. Append only, never edited or deleted.

Features in scope:
- Ticket list with filters by state, type, priority, and a text search over title and body.
- New ticket form where the fields shown change by type: change tickets additionally ask for rollback_plan and planned_window, stored as JSON in an extra_fields column.
- Ticket detail page: state transition buttons, comment box, linked asset, and the full audit log rendered as a timeline.
- Assets page: create, list, and see all tickets touching an asset.
- A "Weekly" view: tickets closed in the last 7 days and anything still open past its due date.
- Export everything to a single JSON file via a button, and a CSV export of tickets.

Explicitly out of scope, do not build: SLAs, approval chains, discovery agents, email ingestion, multi-user roles, SSO, a workflow designer.

Deliver: a README with setup in three commands, a seed script that inserts 12 sample tickets and 5 assets, and one Vitest file covering that state changes always write an events row.

## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.