Plant Ops Copilot Cursor Rules Template for Summarizing Shift Logs and Machine Incidents

Overview

This Cursor rules configuration enables building an AI copilots for plant supervisors that summarize shift logs and machine incidents. It targets a Node.js/TypeScript runtime with a PostgreSQL backend using TypeORM. The template ensures deterministic, auditable outputs suitable for dashboards and maintenance reviews. Direct answer: paste the copied .cursorrules block into your project root to activate a plant-ops-focused summarization copilot.

When to Use These Cursor Rules

• When you need concise daily shift-log summaries for plant leadership.
• When incident reports require structured, timestamped narratives with risk flags.
• When generating audit-ready outputs for safety and regulatory reviews.
• When you want a reusable copilot pattern across multiple production lines.

Copyable .cursorrules Configuration

// Cursor Rules Template for Plant Ops Copilot
Framework Role & Context:
You are a Cursor AI copilot for plant operations. You ingest ShiftLog and Incident records and produce concise, structured summaries suitable for supervisors and incident reviews. Preserve timestamps, highlight critical incidents, and avoid unverified facts. Your outputs should be concise, structured, and easily ingested by dashboards.

Code Style and Style Guides:
- Language: TypeScript (Node.js) for the copilot runtime
- Formatting: Prettier with 2-space indentation
- Documentation: JSDoc on public APIs
- Avoid global mutable state; use dependency injection

Architecture & Directory Rules:
- Project root contains src/
- Copilot logic under src/coplots/plant_ops_copilot/
- Data connectors under src/connectors/
- Models under src/models/
- Tests under tests/
- Do not introduce irrelevant folders or technologies

Authentication & Security Rules:
- Use environment-based secrets; redact credentials in all outputs
- No PII exposure; redact or hash personal data where possible
- All logs must be encrypted at rest; access controlled via service accounts

Database and ORM patterns:
- PostgreSQL as the primary store
- TypeORM with repository pattern
- Entities: ShiftLog, Incident, CopilotOutput, AuditLog
- Use parameterized queries; avoid string interpolation in SQL

Testing & Linting Workflows:
- Unit tests with Jest; integration tests for data ingestion paths
- Lint using ESLint; formatting with Prettier
- CI runs lint, unit tests, and type checks on push

Prohibited Actions and Anti-patterns:
- Do not fabricate incident details; reference sources when possible
- Do not bypass access controls; enforce auth for data reads
- Do not log secrets or raw credentials in any output

Recommended Project Structure

plant-ops-copilot/
├── src/
│   ├── copilots/
│   │   └── plant_ops_copilot/
│   │       ├── summarize.ts
│   │       └── rules.ts
│   ├── connectors/
│   │   └── logs.ts
│   │       
│   ├── models/
│   │   ├── ShiftLog.ts
│   │   ├── Incident.ts
│   │   ├── CopilotOutput.ts
│   │   └── AuditLog.ts
│   └── index.ts
├── tests/
├── config/
├── package.json
└── tsconfig.json

Core Engineering Principles

• Deterministic outputs: fix language and data shapes to avoid variability.
• Auditable AI: always produce source references and timestamps.
• Security by default: redact PII and secrets in all outputs.
• Single-responsibility: 1 file per data path (logs, incidents, outputs).
• Test-driven safety: unit, integration, and contract tests for copilot behavior.

Code Construction Rules

• Strict typing in TypeScript; export only well-typed interfaces.
• Use repository pattern for data access; avoid raw SQL strings in code paths.
• Output schema: CopilotOutput must include summary, timestamp, line-item references, and source IDs.
• Input ingestion: normalize ShiftLog and Incident data to a stable internal model before summarization.
• Logging: log all outputs to AuditLog with user context and request IDs.
• Performance: implement streaming where possible; cap memory usage per request.
• Do not hardcode credentials; use environment configuration and secret management.

Security and Production Rules

• Encrypt data at rest and in transit; rotate credentials regularly.
• Enforce strict access controls; data reads require valid service tokens.
• Sanitize inputs and outputs; redact PII in all user-visible content.
• Implement rate limiting and request validation to prevent abuse.
• Monitor for anomalies; alert on high-risk incidents flagged by the copilot.

Testing Checklist

• Unit tests cover normalization and summarization logic.
• Integration tests validate data ingestion from ShiftLog and Incident sources.
• End-to-end tests ensure .cursorrules outputs are produced and stored.
• Security tests verify secret masking and auth enforcement.
• CI runs lint, tests, and type checks on each PR.

Common Mistakes to Avoid

• Overly long summaries; prefer structured bullet outputs for dashboards.
• Ignoring timestamps and data provenance in summaries.
• Exposing secrets or using hardcoded credentials.
• Neglecting sanitization of PII in logs and outputs.

Related implementation resources: AI Agent Use Case for Industrial Plants Using Sensor Logs To Monitor and Flag Workplace Noise Levels Exceeding Regulatory Limits and Human approval rules for AI coding agents in production.

FAQ

What is this Cursor Rules Template used for in plant operations?

This template provides a copyable .cursorrules block to configure a Cursor AI copilot that ingests ShiftLog and Incident data and outputs concise, auditable summaries for supervisors and incident reviews.

Which stack is assumed for this template?

The template targets a Node.js/TypeScript runtime with PostgreSQL using TypeORM. The template emphasizes deterministic outputs and audit-ready summaries for production plant environments.

How should data sources be structured for the copilot?

Data should flow from connectors into normalized internal models (ShiftLog, Incident) and then through the summarization engine, with source references stored in CopilotOutput.

What are the security constraints?

Do not log credentials, redact PII, encrypt data at rest, and require valid service tokens to access data.

What tests should I prioritize?

Unit tests for normalization, integration tests for ingestion, and end-to-end tests for .cursorrules generation and storage, plus security checks in CI.

How do I avoid anti-patterns with this template?

Avoid hardcoding values, bypassing auth, fabricating incidents, or skipping provenance. Prefer reproducible outputs and clear source references for every summary.