Problem
We post gigs directly in Discord today, but we do not persist a first-class local record for the gig or its applicant lifecycle. We also do not have a consistent command-driven way to move the gig through its recruiting states and reflect those state changes back into the Discord post itself.
We need one workflow for:
- creating a pending gig record from a Discord gig post
- tracking applicants / suggested people against that gig
- updating gig status through Discord commands
- editing the original Discord gig post when the status changes
- keeping Discord-visible tags in sync with the internal status
Scope
Implement pending-gig tracking for gigs posted in the Discord gigs channel.
Suggested behavior:
- Ingest a gig post from Discord into Postgres as a
pending_gig engagement
- Store Discord provenance (
guild_id, channel_id, message_id, poster, timestamps)
- Allow applicant / candidate rows to be attached to the gig
- Add Discord commands to update lifecycle status
- When status changes, update the original Discord post title/body/tagging to reflect the new state
Discord Status Tags
Support at least these visible Discord tags / prefixes:
[RECRUITING]
[FILLED]
[OUTDATED]
[UNKNOWN]
Internal status can be more detailed, but these are the minimum external states that should be mirrored onto the post.
Suggested Command Surface
Examples:
- mark gig as recruiting
- mark gig as filled
- mark gig as outdated
- mark gig as unknown
- add/remove applicant
- list applicants for a gig
Exact slash-command names can be decided during implementation, but they should be staff-usable and auditable.
Data Model Notes
This issue should cover the local tables needed for the pending-gig stage only, including at minimum:
- gig/engagement record
- applicant/candidate linkage
- event/audit history for status changes
Acceptance Criteria
- A gig posted in the Discord gigs channel can be persisted as a local
pending_gig record
- The local record stores stable Discord identifiers for the original post
- Applicants / suggested people can be associated with the gig
- Staff can update gig status through Discord commands
- Status changes update the original Discord gig post so the visible tag matches the internal state
- Supported visible states include
[RECRUITING], [FILLED], [OUTDATED], and [UNKNOWN]
- Status changes are auditable
Parent
Part of #249
Problem
We post gigs directly in Discord today, but we do not persist a first-class local record for the gig or its applicant lifecycle. We also do not have a consistent command-driven way to move the gig through its recruiting states and reflect those state changes back into the Discord post itself.
We need one workflow for:
Scope
Implement pending-gig tracking for gigs posted in the Discord gigs channel.
Suggested behavior:
pending_gigengagementguild_id,channel_id,message_id, poster, timestamps)Discord Status Tags
Support at least these visible Discord tags / prefixes:
[RECRUITING][FILLED][OUTDATED][UNKNOWN]Internal status can be more detailed, but these are the minimum external states that should be mirrored onto the post.
Suggested Command Surface
Examples:
Exact slash-command names can be decided during implementation, but they should be staff-usable and auditable.
Data Model Notes
This issue should cover the local tables needed for the pending-gig stage only, including at minimum:
Acceptance Criteria
pending_gigrecord[RECRUITING],[FILLED],[OUTDATED], and[UNKNOWN]Parent
Part of #249