docs: introduce Mercury Notebook Deliverable Pattern
This commit is contained in:
152
docs/Pattern_Outline_V1-00.md
Normal file
152
docs/Pattern_Outline_V1-00.md
Normal file
@@ -0,0 +1,152 @@
|
||||
# [Pattern Name] Pattern v1.0.0
|
||||
|
||||
One-sentence description of what this pattern standardizes and which Django applications use it.
|
||||
|
||||
## 🐾 Red Panda Approval™
|
||||
|
||||
This pattern follows Red Panda Approval standards.
|
||||
|
||||
---
|
||||
|
||||
## Why a Pattern, Not a Shared [Implementation]
|
||||
|
||||
Explain the domain variability that makes a single shared model/function/utility impractical.
|
||||
|
||||
List concrete examples of how different domains need different behavior:
|
||||
|
||||
- A [domain A] app needs [field/behavior X]
|
||||
- A [domain B] app needs [field/behavior Y]
|
||||
- A [domain C] app needs [field/behavior Z]
|
||||
|
||||
Instead, this pattern defines:
|
||||
|
||||
- **Required [fields/interface]** — every implementation must have
|
||||
- **Recommended [fields/behaviors]** — most apps should include
|
||||
- **Extension guidelines** — for domain-specific needs
|
||||
- **Standard choice values** — for interoperability
|
||||
|
||||
---
|
||||
|
||||
## Required [Fields / Interface]
|
||||
|
||||
The non-negotiable minimum every implementation must provide.
|
||||
|
||||
```python
|
||||
# Required fields or function signature
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Standard Choice Values
|
||||
|
||||
Use these exact values for interoperability between apps.
|
||||
|
||||
### CHOICE_A
|
||||
|
||||
```python
|
||||
CHOICE_A = [
|
||||
("value-a", "Label A"),
|
||||
("value-b", "Label B"),
|
||||
]
|
||||
```
|
||||
|
||||
### CHOICE_B
|
||||
|
||||
```python
|
||||
CHOICE_B = [
|
||||
("value-x", "Label X"),
|
||||
("value-y", "Label Y"),
|
||||
]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recommended [Fields / Behaviors]
|
||||
|
||||
Fields or behaviors that most apps should include but are not strictly required.
|
||||
|
||||
```python
|
||||
# Recommended additions
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## [Pattern Variant 1]
|
||||
|
||||
Description of the first common implementation approach.
|
||||
|
||||
```python
|
||||
# Code example
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## [Pattern Variant 2]
|
||||
|
||||
Description of the second common implementation approach.
|
||||
|
||||
```python
|
||||
# Code example
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## [Pattern Variant 3]
|
||||
|
||||
Description of a third approach (e.g., background task, management command, signal).
|
||||
|
||||
```python
|
||||
# Code example
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Domain Extension Examples
|
||||
|
||||
### [Domain A] App
|
||||
|
||||
```python
|
||||
# Domain-specific extension example
|
||||
```
|
||||
|
||||
### [Domain B] App
|
||||
|
||||
```python
|
||||
# Domain-specific extension example
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- ❌ Don't [common mistake 1]
|
||||
- ❌ Don't [common mistake 2]
|
||||
- ❌ Don't [common mistake 3]
|
||||
|
||||
---
|
||||
|
||||
## Settings
|
||||
|
||||
Document any Django settings this pattern recognizes:
|
||||
|
||||
```python
|
||||
# settings.py
|
||||
SETTING_NAME = default_value # Description of what it controls
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing
|
||||
|
||||
Standard test cases every implementation should cover.
|
||||
|
||||
```python
|
||||
class My[Pattern]Test(TestCase):
|
||||
def test_[happy_path](self):
|
||||
"""[Happy path scenario]."""
|
||||
pass
|
||||
|
||||
def test_[edge_case](self):
|
||||
"""[Edge case or negative test]."""
|
||||
pass
|
||||
```
|
||||
Reference in New Issue
Block a user