Local tickets

Fossil's tickets are artifacts, and artifacts are forever: every typo, duplicate and piece of spam a tracker accepts becomes part of the repository's permanent, synchronized history. That is the right property for the tickets that matter — provenance you can trust decades later — and the wrong one for an open intake door.

Quarry adds a second tier in front of the artifact log. A local ticket lives in the forge's own database (oltp), never in the zit store. It renders in the same tracker views, wears the same fields and vocabulary, and can be triaged like any other ticket — but it does not sync, it can be deleted outright, and it enters the fossil only when an admin promotes it.

The two tiers

	local ticket	fossil ticket
lives in	forge database (oltp)	zit store (artifacts)
filed by	anyone holding cap n	signed-in accounts, n
deletable	yes — discard, gone	no (shun is the only out)
travels with clone	no	yes
promoted	by an admin, one click	is the promotion target

Who may file

The gate is fossil's own capability system — no new settings surface. ticket.intake (the local door) requires capability n, resolved through the category closure:

• Stock behaviour: any signed-in account holds the anonymous category (hmnc — n included), so members file local tickets freely.
• Open intake to strangers: grant n to the nobody category for that repository in settings. Visitors then file local tickets without an account. The web form adds a honeypot field and a per-address rate limit; a discarded spam ticket vanishes without trace.
• Close intake: blank n from the categories, as fossil admins always have.

Filing directly into the fossil is unchanged: ticket.new still requires a signed-in account with n, and the web form offers it only to those who hold it.

The fields a tracker defines

A fossil tracker's schema is the repository's own: it may define whatever columns it likes, and across the stores this forge mirrors they do — every one carries type, severity, priority, subsystem and foundin, and several add assignee, closer, submitter and closedate. Quarry has always READ all of them. It could write only fossil's defaults, which made it a second-class client of its own stores: a tracker with an assignee could be read here and edited only in fossil.

Both write ops — ticket.new and ticket.set, and the local ticket.intake — take a generic fields map beside the named inputs, and the forms render one text input per column under fields.<name>. Three rules bound it:

• The tracker's vocabulary is the gate. A name the tracker does not already carry is refused. Fossil creates a column on demand, so an unchecked map would make every ticket write a schema migration, and one typo would leave a tracker with an assigne column forever. The vocabulary is read from the tickets themselves (ticket.config reports it as fields): there is no verb that reports a schema, so what the tickets carry is the answer, and a column nobody ever set is one no form needs to offer.
• A field with its own input is refused here. One value with two doors is a disagreement waiting for its first save.
• What fossil withholds, quarry does not author. private_contact and contact are labelled "Not publicly visible" in fossil's own template; writing one through a forge form would put an address into a permanent, synchronized record from a page that never showed it.

An empty value CLEARS the field — the only way to unset one somebody set by mistake. A local ticket is gated on the same vocabulary as the fossil tier, because promotion lands it in that tracker.

Identity and links

Local tickets mint random 40-hex ids, so /r/{repo}/ticket/{id} and [/tktview/…] references work identically across tiers. Listings mark local rows with a local chip and filter on is:local.

Promotion

Promotion is deliberate distillation, not replay. An admin promoting a local ticket writes two artifacts: one ticket new carrying the folded field state and description, with provenance recorded in the text (reported by whom, when, promoted by whom); and, when discussion exists, one ticket set whose comment collates it verbatim, each entry prefixed with its author and date. The change-by-change history of the local tier is working noise and stays out of the permanent log — that is the point of the tier.

After promotion the local id becomes a tombstone: the old URL redirects to the fossil ticket forever, and the mapping is the only thing kept.

What to know before relying on it

Local tickets live in one forge's data directory. They do not clone, do not sync, and are not recovered by rebuilding a forge from the store — back up the oltp database if the intake queue matters to you. Anything whose loss would hurt belongs in the fossil: promote it.