Agentic-Shiksha / Backend
Copilot instructions1 starsChanged 45 days agoMITView on GitHub
Single-service Python 3.13.5 FastAPI backend on Azure (AI Foundry agents, Cosmos DB, Blob, AI Search), with Python 3.11 compatibility retained in CI. Follow every rule below. Flag any rule you must break and why.
- Reads credentials
Where files are headingNew Copilot instructions files have more rules about branches and pull requests, and fewer about code style.
Of the Copilot instructions files we read, the 2,336 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repositoryOne other file it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
The file
We split this copilot-instructions.md into the rules it gives an agent
12 rules. About 0 are common, 4 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 7
Treat repo memory files as hints only.
- Distinctive: line 8
Never guess file locations - search first.
- Distinctive: line 9
When generating code, include the matching test in the same output.
- Very specific: line 10
Ask which router/domain if placement is ambiguous - never add to backend/main.py.
- Very specific: line 13
Never put credentials, tokens, connection strings, or copied .env values in PLAN.md.
- Distinctive: line 18
No credential fallbacks in code.
- Very specific: line 19
Every endpoint that reads or writes user/org data requires auth via shared dependencies: get_current_active_user() / require_roles(...).
- Very specific: line 20
Use SecretStr for secrets in settings.
- Very specific: line 26
When touching an existing main.py endpoint, migrate it to its router in the same PR if the change is non-trivial.
- Very specific: line 31
All environment access through pydantic_settings.BaseSettings models (Azure, auth, storage, models, CORS).
- Very specific: line 36
Every route: typed Pydantic request model and response_model=.
- Very specific: line 66
Every bugfix ships a regression test.
≈ “Common” is an estimate: at least 1 in 5 of the 3,779 Copilot instructions files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Copilot Instructions - EKALAIVA Backend (Python / FastAPI / Azure)
Single-service Python 3.13.5 FastAPI backend on Azure (AI Foundry agents, Cosmos DB, Blob, AI Search), with Python 3.11 compatibility retained in CI. Follow every rule below. Flag any rule you must break and why.
Ground rules for you (the agent)
- Treat repo memory files as hints only. Re-verify any security, metric, or line-count claim against the working tree (
git ls-files, grep) before reporting it. - Never guess file locations - search first.
- When generating code, include the matching test in the same output.
- Ask which router/domain if placement is ambiguous - never add to
backend/main.py. PLAN.mdis the tracked source of truth for the compliance refactor. Read it before acting, execute only its active phase, and update each item toaccomplished,in_progress, ornot_startedonly after verifying the working tree.- Complete one
PLAN.mdphase per session or PR. Stop after its acceptance checks, record the phase report, and report files changed, checks run, and unresolved work before starting another phase. - Never put credentials, tokens, connection strings, or copied
.envvalues inPLAN.md.
Security (non-negotiable)
.envmust never be tracked..env.example(value-free) is the contract. If you find a tracked secret file: stop, tell me, do not copy its values anywhere.- No credential fallbacks in code. No hardcoded client secrets, JWT secrets, endpoints, or resource IDs. App must fail at startup if a required secret is missing - never fall back to a predictable default.
- Every endpoint that reads or writes user/org data requires auth via shared dependencies:
get_current_active_user()/require_roles(...). These verify JWT -> re-fetch user from Cosmos -> requirestatus == "active"-> enforce role. Missing/invalid auth is 401/403 - NEVER a bypass, NEVER treated as admin. No "Dashboard mode" exceptions. - Use
SecretStrfor secrets in settings. Never log secret values. - CORS origins come from settings, never inline, never
*with credentials.
Structure
backend/main.pyis frozen for new routes. New endpoints go inrouters/<domain>.py(auth, agents, chat, directory, knowledge, ...), request/response models inschemas/<domain>.py, shared deps independencies/. App assembled viacreate_app()keeping the existinglifespan.- When touching an existing
main.pyendpoint, migrate it to its router in the same PR if the change is non-trivial. __init__.pystays thin: re-exports +__all__only. Heavy imports (torch, transformers, large SDKs) lazy-load inside the class that needs them.
Config
- All environment access through
pydantic_settings.BaseSettingsmodels (Azure, auth, storage, models, CORS). No newos.getenvcalls anywhere. - Settings validated at startup; enabled feature + missing secret = crash with a clear message.
API boundaries
- Every route: typed Pydantic request model and
response_model=. NoDict[str, Any]payloads on external endpoints. - Write-request models:
model_config = ConfigDict(extra="forbid"). Field(default_factory=list)- never mutable defaults.model_validate()when ingesting Cosmos records, webhook payloads, or LLM JSON output. Define the Pydantic schema before generating structured output; validate the response against it.- Pydantic is for boundaries. Internal temporaries may be dataclasses/plain types.
Reliability
- Tenacity on transient failures only (429, timeouts, 5xx), exponential backoff, respect
Retry-After. NEVER retry non-idempotent creates/writes. Account for Azure SDK built-in retry before stacking your own. - Expensive clients (
AIProjectClient,SearchClient,BlobServiceClient) come from a singleton registry built at startup and cleaned up inlifespan- never constructed per request. Cosmos client already follows this; match it. - Long-running jobs (agent creation, deep research): persist a job record in Cosmos -
{id, status: PENDING|RUNNING|COMPLETED|FAILED, attempts, progress, output_ref}- with idempotency keys and resume support. No fire-and-forget daemon threads or bare BackgroundTasks for work that must survive restart. Status via SSE or webhook PLUS a pollable status endpoint.
Logging
logging.getLogger(__name__)in all modules.print()forbidden in library/service code (CLI/migration scripts exempt). Include correlation/job IDs in job-related logs.
Prompts
- Prompts live in
prompt_store/as versioned files, never inline strings in Python. Markdown is fine - do not convert to YAML. Move any remaining inline system prompts into the store. Each prompt states its scope restriction explicitly.
Abstractions
- ABC +
@abstractmethodonly for genuinely interchangeable implementations with required contracts. Optional lifecycle hooks (e.g.before_chat/after_chat) stay as overridable no-ops - do not make them abstract.
Packaging
- Target:
pyproject.toml+uv.lock(or Poetry), dev group with pytest + ruff, pinned Python 3.13.5 runtime while retaining Python 3.11 compatibility. Until migrated, keeprequirements.txtfully pinned. Do not start a disruptivesrc/re-layout without being asked.
Testing & CI
- Every bugfix ships a regression test. New auth/config/persistence logic ships unit tests. Organize tests by behavior, not one-file-per-class.
- Priority test areas: auth/authz (including disabled users and missing-token paths), settings validation, job state transitions + idempotency, structured-output validation, Cosmos boundaries.
- CI on every PR: ruff (format+lint), pytest, gitleaks, CodeQL. No merge on red.
Docs
- Root README = model card: overview, Mermaid architecture, intended use, out-of-scope, limitations, setup. Per-module READMEs carry copy-paste run commands. Documented endpoints must match actual routes - update docs in the same PR that changes behavior.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

