Instructions for directing GPTs

Here is an updated set of instructions for producing and revising code for your project. The specific references to the three models are removed, but all the general strict requirements are retained to ensure consistency, modularity, and accuracy across the project.

General Instructions for Producing and Revising Code in This Modularized Django Project

1. Carefully Analyze Existing Models and Project Structure

Before producing or revising any code, analyze the project's modular structure:
- teaching/models.py
- assessment/models.py
- learning/models.py
- common/models.py
- school/models.py
Fully understand the patterns and conventions used within each models.py file:
- Naming conventions for models, fields, and relationships.
- Inheritance patterns (e.g., use of TimeStampedModel or other base models).
- Soft deletion patterns (is_active field and soft_delete() method).
- Change tracking with HistoricalRecords().
- Meta options like verbose_name, verbose_name_plural, indexes, and permissions.

2. Ensure Modular Placement of Code

Place models in the correct models.py file based on their role:
- Teaching-related models should go in teaching/models.py.
- Assessment-related models should go in assessment/models.py.
- Learning objectives and related models should go in learning/models.py.
- Common models that may be shared across different apps should go in common/models.py.
- School-related models should go in school/models.py.
Cross-reference models between apps: Ensure relationships (e.g., ForeignKey, ManyToManyField) reference models accurately across the different apps.

3. Update `admin.py` for Each App

For every new model or model revision, ensure the corresponding admin.py file is updated for that app:
- Example: If a model is added to teaching/models.py, update teaching/admin.py to register the model with Django Admin.
- Follow the same registration patterns used in the existing admin.py files, ensuring proper admin management of models.
- Example:
```
from django.contrib import admin
from .models import YourModelName

admin.site.register(YourModelName)
```

4. Follow Programming Patterns and Precedents from Existing Models

All new models and revisions must follow the exact naming conventions, relationships, and field types already used in the corresponding app.
Maintain consistent style and structure for fields (e.g., blank=True, null=True, default values).
Ensure that ForeignKey and ManyToManyField relationships use appropriate related_name and on_delete behavior based on existing models.

5. Soft Deletion and Historical Records

Soft deletion:
- If a model requires soft deletion, include is_active = models.BooleanField(default=True) to indicate whether the record is active.
- Add a soft_delete() method to set is_active to False without actually deleting the record.
Historical Records:
- If change tracking is used in the app, ensure that new or revised models include HistoricalRecords() for auditing purposes.
- Use the existing setup for change history as seen in other models.

6. Meta Class: Internationalization, Auto-Documentation, and Optimization

Internationalization (i18n):

Wrap all translatable text (e.g., verbose_name, help_text) in gettext_lazy to provide future translation capabilities.

Example:

from django.utils.translation import gettext_lazy as _

name = models.CharField(max_length=255, verbose_name=_('Model Name'), help_text=_('Description of the model.'))

Auto-Documentation:
- Add docstrings to models, fields, and methods to provide clarity for auto-generated documentation (e.g., using Django Rest Framework or Sphinx).
- Ensure fields have meaningful help_text for documentation and admin clarity.
Indexes and Permissions:
- Add indexes for fields that will be frequently queried (e.g., is_active, course, department):
```
models.Index(fields=['field_name'])
```
- Include appropriate permissions for role-based access control, ensuring that permissions match existing patterns across the project:
```
permissions = [
   ("manage_model_name", "Can manage model name"),
]
```

7. Inheritance and Abstract Models

When multiple models share the same fields or methods, consider creating an abstract base class to reduce redundancy.
Use abstract = True in the Meta class to ensure the base model itself does not create a database table:
```
 class AbstractModel(TimeStampedModel):
     class Meta:
         abstract = True
```

8. Field Defaults for Migrations

Always provide default values for new fields to ensure migration safety:
- For text fields, use the verbose name as a reasonable default to prevent migration errors:
```
default='Field Verbose Name'
```

9. Handle Hierarchies with Parent-Child Relationships

For models requiring hierarchical relationships, use self-referencing foreign keys with optional relationships:

 parent_model = models.ForeignKey('self', on_delete=models.SET_NULL, null=True, blank=True, related_name='sub_models')

Ensure the hierarchical structure is flexible and optional, unless explicitly required.

10. Avoid Redundancy and Unnecessary Fields

Do not introduce redundant models or fields unless absolutely necessary:
- For example, if Department already handles subject domains, avoid creating a new Subject model unless explicitly required.
Avoid unnecessary complexity: If the user has a simpler method of managing data, do not introduce over-engineered solutions.

11. Cross-Check and Update All Related Files

Cross-check and update all files that reference the models, including:
- models.py in other apps, to ensure correct relationships.
- admin.py, to ensure models are registered properly for Django Admin.
- forms.py, serializers.py, and views.py, if models are referenced in forms or APIs.
Ensure that all files are accurately updated to reflect changes made in the models, ensuring no references are left out.

12. Clarify with the User When in Doubt

Seek clarification from the user if there is any ambiguity regarding the model structure, placement, or any other aspect of the project.
Be explicit in asking about:
- Expected inheritance patterns.
- Field behavior, especially defaults or constraints.
- Which app models belong to and any future plans for migration between apps.

13. Test Migrations and Model Behavior

Run migrations locally after creating or modifying models to ensure that they proceed without errors.
Check the model’s behavior in Django Admin or the application to validate that all relationships, fields, and methods behave as expected.

This comprehensive set of instructions ensures that all code created or revised for this project follows the established modular structure, adheres to existing conventions, and provides clarity for future development. Let me know if there are any further refinements needed!

davidorex / learning_workshop