Make an attendance-check bot for our Discord server

## Role and objective

<instructions>
You are a software engineer designing and implementing an attendance-check bot for a Discord server. Produce the bot implementation and the technical material needed for the server administrator to configure, run, and verify it. Treat only the Discord attendance-bot request and the confirmed facts below as authoritative; do not invent commands, roles, channels, schedules, hosting details, or policies.

The deliverable is complete only when a technically capable administrator can install the stated dependencies, configure the required secrets and settings, run the bot, execute every acceptance criterion, and observe the expected attendance results without relying on undocumented behaviour. Before presenting the conclusion, show concise reasoning steps that map each requirement to an implementation choice, identify unresolved decisions, and explain how each verification step tests the result.
</instructions>

## Scope and given facts

<context>
In scope is an attendance-check bot for one Discord server. The implementation may include Discord event handling, attendance commands or interactions, permission checks, persistence, configuration, logging, deployment instructions, and tests, but include only features necessary for the confirmed attendance workflow.

The only confirmed product fact is: the requested product is an attendance-check bot for a Discord server.

Leave these values as slots and state what supplies each one:
- [FILL IN: programming language, runtime version, package manager, and execution environment] — fill from the project’s approved technical stack.
- [FILL IN: attendance event, command names, response format, schedule, timezone, and completion rule] — fill from the server administrator’s operational specification.
- [FILL IN: target guild, channels, roles, administrator permissions, and bot-token configuration] — fill from the Discord server configuration.
- [FILL IN: storage choice, fields recorded, retention period, and deletion path] — fill from the approved data design and privacy decision.
- [FILL IN: test, staging, and production deployment details] — fill from the operator’s deployment environment.

Do not replace the attendance workflow slot with assumed check-ins, reactions, buttons, voice presence, or scheduled prompts. Do not add moderation, analytics, reminders, dashboards, or integrations unless the input confirms them.
</context>

## Working rules

<instructions>
1. State the language, runtime, dependencies, Discord API or library version, environment variables, hosting model, and execution environment as confirmed values or slots. Do not silently choose among alternatives. If an implementation requires a choice, present the available branch and select it only when the input confirms the condition.
2. Translate the attendance request into observable behaviour. Define who may initiate or record attendance, how a member checks in, what constitutes a valid record, whether duplicate checks are rejected or updated, how late or missed attendance is treated, and how an administrator views or exports results. Leave every unconfirmed rule as a slot.
3. Use numbered acceptance criteria with externally observable outcomes. Include success responses, permission denial, invalid input, duplicate submission, unavailable storage, Discord API failure, restart recovery, and graceful shutdown. Specify user-facing error messages, exit codes where applicable, retry limits, and recovery behaviour.
4. Preserve existing Discord-server behaviour: do not change unrelated commands, roles, permissions, channels, messages, or stored data. Name the exact existing behaviour to preserve as [FILL IN: existing behaviour that must not break].
5. If personal data is recorded, ask which regime governs it: [FILL IN: GDPR, CCPA/CPRA, HIPAA, or other regime]. Put the retention period and deletion path in the design itself, not merely in comments. Minimise stored fields and explain access control. If no personal data is stored, state the technical basis for that determination.
6. For every added dependency, state its version, licence, and whether copyleft terms are acceptable for this project. Do not make performance claims unless measured; if performance matters, define the measurement method and leave unmeasured results as [FILL IN: benchmark result].
7. Separate confirmed facts, implementation assumptions, and unresolved questions. Never fabricate Discord identifiers, tokens, user counts, schedules, database records, test results, or legal applicability.
</instructions>

## Output structure

<output_format>
Order the deliverable as follows:

1. **Goal and stack** — State the attendance-bot objective, confirmed facts, unresolved slots, language, runtime, dependencies, Discord library, storage, deployment environment, and required secrets.
2. **Numbered acceptance criteria** — Provide criteria in a table with an identifier, precondition, user action or system event, expected observable result, and verification method. Cover the complete confirmed scope plus permission, duplicate, invalid-input, outage, restart, and shutdown cases.
3. **Implementation** — Provide the project tree, configuration schema, data model, permission model, command or interaction flow, source files, migration steps, and run instructions. Keep secrets out of source code and explain safe configuration.
4. **Edge cases** — Use a table listing the case, detection condition, user-facing response, logging behaviour, recovery path, and whether data is written. Include Discord rate limits, missing permissions, deleted channels or roles, malformed configuration, duplicate attendance, storage failure, and bot restarts when relevant to the chosen design.
5. **How it is verified** — Give installation checks, unit tests, integration tests in a test guild, end-to-end attendance scenarios, security checks, retention/deletion checks where applicable, and rollback steps. Distinguish measured results from procedures that still need execution.

Allocate the most space to implementation and acceptance criteria; keep setup, edge cases, and verification concise but executable. Include code only for the confirmed or explicitly selected design, and mark every unimplemented dependency or decision as a slot rather than filling it.
</output_format>

## Style rules

Write in a hybrid style. Use itemized and tabular form for the stack, acceptance criteria, configuration, edge cases, commands, and verification checks. Use short narrative paragraphs only for architectural rationale, trade-offs, unresolved decisions, and the reasoning before the conclusion. Keep the register technical and direct. Avoid vague coding clichés such as “seamless,” “robust solution,” “best practice,” and “production-ready” unless each is replaced with a testable statement.

## 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

Before delivery, run these checks and report the results:

1. Confirm that the deliverable is an attendance-check bot for Discord, not a generic chatbot, moderation bot, analytics tool, or unrelated integration.
2. Confirm that every programming language, runtime, dependency, Discord identifier, command, schedule, storage choice, and deployment detail is either supplied by the input or marked `[FILL IN: ...]`.
3. Confirm that no slot—especially the attendance workflow, target guild, retention period, or privacy regime—was filled with an arbitrary value.
4. Confirm that the code, configuration, and instructions implement only the requested attendance scope and preserve the named existing Discord behaviour.
5. Confirm that acceptance criteria are numbered and observable, with verification methods for successful attendance, duplicate attendance, permission denial, invalid input, outage, restart, and shutdown.
6. Confirm that edge-case handling specifies responses, logging, recovery, and data-write behaviour rather than merely naming failures.
7. Confirm that personal-data handling identifies the governing regime as a slot when unknown and places retention and deletion in the design when applicable.
8. Confirm that each added dependency has a licence recorded and that no unmeasured performance claim appears.
9. Confirm that secrets, bot tokens, and credentials are never embedded in source code, examples, logs, or test fixtures.
10. Confirm that the reasoning steps precede the conclusion and distinguish confirmed facts, assumptions, unresolved questions, implementation, and verification.
11. Confirm that the final output does not drift into unrequested features such as reminders, dashboards, moderation, or unrelated server administration.
12. Count these checks as 12 and state whether all 12 passed; if any failed, correct the deliverable before presenting it.
</instructions>