Requests

A request is a trackable unit of intent — a bug report, feature request, initiative, or any other reason work needs to happen. Requests answer the question: “why are we doing this?”

What a request is

Requests sit above specs and tasks in the hierarchy. A spec describes what a subsystem is; a task describes what to do; a request describes why it matters. By linking requests to the work they spawn, you maintain traceability from intent to implementation.

Every request has:

• Title — a short description of the intent
• Description — optional details, context, or reproduction steps
• Origin — where it came from: conversation, bug, idea, user-report, or internal
• Priority — critical, high, normal, or low
• Status — lifecycle state (see below)

Request lifecycle

open -> in-progress -> resolved
                    -> abandoned
                    -> deferred

Status	Meaning
open	Filed but no work started
in-progress	Linked work is underway
resolved	Work complete, outcome recorded
abandoned	Dropped; will not be addressed
deferred	Postponed to a later time

Linking

Requests link to three kinds of work items:

• Tasks — the specific units of work that address the request
• Specs — the subsystems involved in fulfilling the request
• Findings — bugs or ideas from the intake pile related to the request

Link work items to a request with:

jig request link <request-id> --task <spec>/<task>
jig request link <request-id> --spec <spec-name>
jig request link <request-id> --finding <finding-id>

Resolution

When a request is resolved, capture the outcome and what was learned:

jig request resolve <request-id> --outcome resolved --learning "Session tokens now refresh silently via middleware"

Possible outcomes:

Outcome	Meaning
resolved	Fully addressed
partial	Partially addressed; remaining work tracked separately
deferred	Postponed with a plan to revisit
wont-fix	Intentionally not addressing
cant-reproduce	Could not reproduce the reported issue

Learnings

Every resolved request requires a learning — a sentence or two about what was discovered or decided. Learnings accumulate into a searchable knowledge base:

jig request search "auth token refresh"

This searches across request titles, descriptions, and learnings. Over time, learnings prevent the same questions from being re-investigated.

CLI commands

jig request create "Title" --description "Details" --priority high
jig request list
jig request list --status open
jig request show <id>
jig request link <id> --task <spec>/<task>
jig request resolve <id> --outcome resolved --learning "What we learned"
jig request defer <id> --reason "Waiting on upstream API"
jig request search "keyword"

See CLI Reference for full details on all request subcommands.