Make an attendance-check bot for our Discord server

BRIEF

## Role and objective

You are a software engineer designing and implementing an attendance-check bot for the user's Discord server. Produce a complete, runnable bot implementation or, if essential requirements remain unresolved, produce the smallest implementation-ready specification and clearly marked code slots for those requirements. The intended audience is the server owner or administrator.

The deliverable must be ordered as goal and stack, numbered acceptance criteria, edge cases, and how it is verified. Completion means that an administrator can configure, run, test, and operate the bot using only the delivered implementation and instructions, without relying on invented server-specific details.

## Scope and given facts

In scope is a bot that checks attendance in a Discord server. The user has not specified the attendance event, schedule, command or interaction method, role permissions, storage system, reporting format, hosting environment, or programming stack.

Treat only “attendance-check bot” and “Discord server” as confirmed facts. Leave every other value unresolved using explicit slots:

- [FILL IN: programming language]
- [FILL IN: runtime and version]
- [FILL IN: Discord library and version]
- [FILL IN: hosting or execution environment]
- [FILL IN: attendance workflow and trigger]
- [FILL IN: commands, buttons, reactions, or scheduled checks]
- [FILL IN: attendance status values]
- [FILL IN: authorised roles or users]
- [FILL IN: persistence and reporting requirements]

State in one line how each slot is filled: the user must provide it, or the implementation must use a documented default only after the user explicitly approves that default. Do not invent a server name, channel ID, token, schedule, role, database, attendance policy, or deployment provider.

## Working rules

First identify the smallest viable attendance workflow. If the user supplies a trigger, use it; if not, ask for the trigger before claiming the bot is complete. Branch explicitly: if attendance is recorded through commands, define command syntax and permission checks; if through buttons or reactions, define the interaction lifecycle; if through a schedule, define the timezone, recurrence, opening window, and close behaviour as slots.

State the language, runtime, dependencies, versions, and execution environment as confirmed values or slots. Do not silently choose them. Treat the Discord bot token as a secret: read it from environment configuration, never hard-code it, print it, or include a real token in examples.

Define numbered, observable acceptance criteria. Include at least successful attendance recording, duplicate handling, unauthorised use, invalid input, persistent storage or an explicitly approved in-memory limitation, administrator configuration, and a way to inspect or export attendance if that is in scope. Name existing behaviour that must not break: ordinary Discord server operation, unrelated channels and commands, and permissions not granted to the bot.

Specify failure behaviour, including user-facing error messages, logging behaviour, exit or process status where applicable, retry handling, and recovery after restart. Cover Discord API failures, missing permissions, unavailable storage, malformed configuration, rate limits, duplicate submissions, late submissions, and ambiguous user identity.

If the bot touches personal data such as Discord user IDs, usernames, attendance history, or timestamps, ask which regime governs it: [FILL IN: GDPR, CCPA/CPRA, HIPAA, or other applicable regime]. Require [FILL IN: retention period] and [FILL IN: deletion path] to appear in the design, not only in a comment. For every added dependency, identify its licence and whether [FILL IN: copyleft terms acceptable for this project] is yes or no.

## Output structure

Use exactly these four top-level parts:

1. Goal and stack  
   State the bot’s attendance purpose, confirmed inputs, unresolved slots, language, runtime, Discord library, dependencies, configuration method, storage approach, and execution environment. Include setup and secret-management requirements. Do not fill unresolved values.

2. Numbered acceptance criteria  
   Write testable criteria with identifiers. Each criterion must state an observable action, expected result, permission condition where relevant, and persistence or reporting consequence. Include criteria for normal attendance, duplicate attendance, invalid requests, unauthorised requests, restart recovery, configuration validation, and Discord or storage failure handling.

3. Edge cases  
   List each edge case with trigger, expected bot response, logging or recovery behaviour, and whether the case is supported, rejected, or awaiting a user decision. Include the attendance window, timezone, late attendance, duplicate identity, deleted channel or role, revoked permissions, rate limits, partial writes, and data deletion as slots where unspecified.

4. How it is verified  
   Provide installation, configuration, unit, integration, permission, failure-recovery, and restart tests. Show commands or test inputs only when confirmed; otherwise use slots. State the expected result for each test and identify any test that cannot run until a named slot is supplied. Do not claim performance or reliability results that were not measured.

## Style rules

Use a hybrid style. Use compact numbered lists and tables for the stack, acceptance criteria, edge cases, configuration slots, and verification cases. Use short narrative paragraphs only to explain the attendance workflow, security decisions, data handling, and unresolved branches. Keep the register technical, direct, and operational. Avoid vague coding clichés such as “robust,” “seamless,” “production-ready,” or “scalable” unless you define and verify the specific property.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is an attendance-check bot for a Discord server, not a generic chatbot or unrelated Discord integration.
2. Confirm that the output follows the required order: goal and stack, numbered acceptance criteria, edge cases, and how it is verified.
3. Check that the language, runtime, Discord library, dependency versions, storage, and execution environment are either supplied by the input or marked with exact [FILL IN: item] slots.
4. Check that no Discord server name, channel ID, role, token, schedule, attendance rule, database, hosting provider, or other value was invented.
5. Check specifically that “[FILL IN: attendance workflow and trigger]” is not filled arbitrarily and that its unresolved consequences are explained.
6. Check that every acceptance criterion is observable and includes the relevant permission, result, and persistence behaviour.
7. Check that duplicate attendance, invalid input, unauthorised use, rate limits, API failures, storage failures, restart recovery, and malformed configuration are addressed.
8. Check that personal-data handling names the applicable regime as a slot and includes retention and deletion paths in the design.
9. Check that each added dependency has a licence identified and that copyleft acceptability is left unresolved when the user did not provide it.
10. Check that ordinary Discord server operation and unrelated functionality are not changed by the proposed bot.
11. Check that no unsupported performance, security, reliability, or compliance claim is presented as measured or confirmed.
12. Check that the work has not drifted into unrelated server moderation, analytics, scheduling, or deployment features unless the attendance workflow requires them.