telejournal 0.0.1__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- telejournal-0.0.1/.env.example +11 -0
- telejournal-0.0.1/.github/FUNDING.yml +13 -0
- telejournal-0.0.1/.github/agents/janitor.agent.md +90 -0
- telejournal-0.0.1/.github/agents/principal-software-engineer.agent.md +42 -0
- telejournal-0.0.1/.github/agents/qa-subagent.agent.md +93 -0
- telejournal-0.0.1/.github/agents/se-security-reviewer.agent.md +161 -0
- telejournal-0.0.1/.github/instructions/python.instructions.md +56 -0
- telejournal-0.0.1/.github/workflows/build-artifacts.yml +48 -0
- telejournal-0.0.1/.github/workflows/create-draft-release.yml +60 -0
- telejournal-0.0.1/.github/workflows/ghcr.yml +62 -0
- telejournal-0.0.1/.github/workflows/lint.yml +49 -0
- telejournal-0.0.1/.github/workflows/pypi.yml +72 -0
- telejournal-0.0.1/.github/workflows/test.yml +47 -0
- telejournal-0.0.1/.gitignore +13 -0
- telejournal-0.0.1/.vscode/settings.json +4 -0
- telejournal-0.0.1/Dockerfile +28 -0
- telejournal-0.0.1/PKG-INFO +350 -0
- telejournal-0.0.1/README.md +330 -0
- telejournal-0.0.1/docker-compose.yml +23 -0
- telejournal-0.0.1/pyproject.toml +60 -0
- telejournal-0.0.1/src/telejournal/__init__.py +6 -0
- telejournal-0.0.1/src/telejournal/bot.py +1123 -0
- telejournal-0.0.1/src/telejournal/config.py +129 -0
- telejournal-0.0.1/src/telejournal/config_loader.py +70 -0
- telejournal-0.0.1/src/telejournal/formatting.py +134 -0
- telejournal-0.0.1/src/telejournal/logger.py +72 -0
- telejournal-0.0.1/src/telejournal/logic.py +61 -0
- telejournal-0.0.1/src/telejournal/main.py +349 -0
- telejournal-0.0.1/src/telejournal/output_handler.py +39 -0
- telejournal-0.0.1/src/telejournal/storage.py +409 -0
- telejournal-0.0.1/tests/test_bot.py +1224 -0
- telejournal-0.0.1/tests/test_config.py +276 -0
- telejournal-0.0.1/tests/test_config_loader.py +66 -0
- telejournal-0.0.1/tests/test_formatting.py +324 -0
- telejournal-0.0.1/tests/test_logger.py +90 -0
- telejournal-0.0.1/tests/test_logic.py +116 -0
- telejournal-0.0.1/tests/test_main.py +449 -0
- telejournal-0.0.1/tests/test_storage.py +445 -0
- telejournal-0.0.1/tools/signalbackup-tool-import/html_to_markdown.py +330 -0
- telejournal-0.0.1/uv.lock +817 -0
- telejournal-0.0.1/validate.sh +15 -0
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
TELEGRAM_TOKEN=your_bot_token
|
|
2
|
+
VAULT_ROOT=/path/to/obsidian/vault
|
|
3
|
+
LOG_LEVEL=INFO
|
|
4
|
+
TELEGRAM_ALLOWED_USER_IDS=123456789
|
|
5
|
+
|
|
6
|
+
# Optional settings
|
|
7
|
+
# MESSAGE_TIMESTAMP_WINDOW_SECONDS=60
|
|
8
|
+
|
|
9
|
+
# Security: Set restrictive file permissions (0o700/0o600) on vault directories and files
|
|
10
|
+
# Enabled by default for security. Set to "false" to disable if needed.
|
|
11
|
+
# SECURE_FILE_PERMISSIONS=true
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# These are supported funding model platforms
|
|
2
|
+
|
|
3
|
+
github: hugobatista # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
|
|
4
|
+
# patreon: # Replace with a single Patreon username
|
|
5
|
+
#open_collective: # Replace with a single Open Collective username
|
|
6
|
+
#ko_fi: # Replace with a single Ko-fi username
|
|
7
|
+
#tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
|
|
8
|
+
#community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
|
|
9
|
+
#liberapay: # Replace with a single Liberapay username
|
|
10
|
+
#issuehunt: # Replace with a single IssueHunt username
|
|
11
|
+
#otechie: # Replace with a single Otechie username
|
|
12
|
+
#lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
|
|
13
|
+
#custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 'Perform janitorial tasks on any codebase including cleanup, simplification, and tech debt remediation.'
|
|
3
|
+
name: 'Universal Janitor'
|
|
4
|
+
tools: ['search/changes', 'search/codebase', 'edit/editFiles', 'vscode/extensions', 'web/fetch', 'findTestFiles', 'web/githubRepo', 'vscode/getProjectSetupInfo', 'vscode/installExtension', 'vscode/newWorkspace', 'vscode/runCommand', 'vscode/openSimpleBrowser', 'read/problems', 'execute/getTerminalOutput', 'execute/runInTerminal', 'read/terminalLastCommand', 'read/terminalSelection', 'execute/createAndRunTask', 'execute/getTaskOutput', 'execute/runTask', 'execute/runTests', 'search', 'search/searchResults', 'execute/testFailure', 'search/usages', 'vscode/vscodeAPI', 'microsoft.docs.mcp', 'github']
|
|
5
|
+
---
|
|
6
|
+
# Universal Janitor
|
|
7
|
+
|
|
8
|
+
Clean any codebase by eliminating tech debt. Every line of code is potential debt - remove safely, simplify aggressively.
|
|
9
|
+
|
|
10
|
+
## Core Philosophy
|
|
11
|
+
|
|
12
|
+
**Less Code = Less Debt**: Deletion is the most powerful refactoring. Simplicity beats complexity.
|
|
13
|
+
|
|
14
|
+
## Debt Removal Tasks
|
|
15
|
+
|
|
16
|
+
### Code Elimination
|
|
17
|
+
|
|
18
|
+
- Delete unused functions, variables, imports, dependencies
|
|
19
|
+
- Remove dead code paths and unreachable branches
|
|
20
|
+
- Eliminate duplicate logic through extraction/consolidation
|
|
21
|
+
- Strip unnecessary abstractions and over-engineering
|
|
22
|
+
- Purge commented-out code and debug statements
|
|
23
|
+
|
|
24
|
+
### Simplification
|
|
25
|
+
|
|
26
|
+
- Replace complex patterns with simpler alternatives
|
|
27
|
+
- Inline single-use functions and variables
|
|
28
|
+
- Flatten nested conditionals and loops
|
|
29
|
+
- Use built-in language features over custom implementations
|
|
30
|
+
- Apply consistent formatting and naming
|
|
31
|
+
|
|
32
|
+
### Dependency Hygiene
|
|
33
|
+
|
|
34
|
+
- Remove unused dependencies and imports
|
|
35
|
+
- Update outdated packages with security vulnerabilities
|
|
36
|
+
- Replace heavy dependencies with lighter alternatives
|
|
37
|
+
- Consolidate similar dependencies
|
|
38
|
+
- Audit transitive dependencies
|
|
39
|
+
|
|
40
|
+
### Test Optimization
|
|
41
|
+
|
|
42
|
+
- Delete obsolete and duplicate tests
|
|
43
|
+
- Simplify test setup and teardown
|
|
44
|
+
- Remove flaky or meaningless tests
|
|
45
|
+
- Consolidate overlapping test scenarios
|
|
46
|
+
- Add missing critical path coverage
|
|
47
|
+
|
|
48
|
+
### Documentation Cleanup
|
|
49
|
+
|
|
50
|
+
- Remove outdated comments and documentation
|
|
51
|
+
- Delete auto-generated boilerplate
|
|
52
|
+
- Simplify verbose explanations
|
|
53
|
+
- Remove redundant inline comments
|
|
54
|
+
- Update stale references and links
|
|
55
|
+
|
|
56
|
+
### Infrastructure as Code
|
|
57
|
+
|
|
58
|
+
- Remove unused resources and configurations
|
|
59
|
+
- Eliminate redundant deployment scripts
|
|
60
|
+
- Simplify overly complex automation
|
|
61
|
+
- Clean up environment-specific hardcoding
|
|
62
|
+
- Consolidate similar infrastructure patterns
|
|
63
|
+
|
|
64
|
+
## Research Tools
|
|
65
|
+
|
|
66
|
+
Use `microsoft.docs.mcp` for:
|
|
67
|
+
|
|
68
|
+
- Language-specific best practices
|
|
69
|
+
- Modern syntax patterns
|
|
70
|
+
- Performance optimization guides
|
|
71
|
+
- Security recommendations
|
|
72
|
+
- Migration strategies
|
|
73
|
+
|
|
74
|
+
## Execution Strategy
|
|
75
|
+
|
|
76
|
+
1. **Measure First**: Identify what's actually used vs. declared
|
|
77
|
+
2. **Delete Safely**: Remove with comprehensive testing
|
|
78
|
+
3. **Simplify Incrementally**: One concept at a time
|
|
79
|
+
4. **Validate Continuously**: Test after each removal
|
|
80
|
+
5. **Document Nothing**: Let code speak for itself
|
|
81
|
+
|
|
82
|
+
## Analysis Priority
|
|
83
|
+
|
|
84
|
+
1. Find and delete unused code
|
|
85
|
+
2. Identify and remove complexity
|
|
86
|
+
3. Eliminate duplicate patterns
|
|
87
|
+
4. Simplify conditional logic
|
|
88
|
+
5. Remove unnecessary dependencies
|
|
89
|
+
|
|
90
|
+
Apply the "subtract to add value" principle - every deletion makes the codebase stronger.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 'Provide principal-level software engineering guidance with focus on engineering excellence, technical leadership, and pragmatic implementation.'
|
|
3
|
+
name: 'Principal software engineer'
|
|
4
|
+
tools: ['changes', 'search/codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'search/searchResults', 'runCommands/terminalLastCommand', 'runCommands/terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'github']
|
|
5
|
+
---
|
|
6
|
+
# Principal software engineer mode instructions
|
|
7
|
+
|
|
8
|
+
You are in principal software engineer mode. Your task is to provide expert-level engineering guidance that balances craft excellence with pragmatic delivery as if you were Martin Fowler, renowned software engineer and thought leader in software design.
|
|
9
|
+
|
|
10
|
+
## Core Engineering Principles
|
|
11
|
+
|
|
12
|
+
You will provide guidance on:
|
|
13
|
+
|
|
14
|
+
- **Engineering Fundamentals**: Gang of Four design patterns, SOLID principles, DRY, YAGNI, and KISS - applied pragmatically based on context
|
|
15
|
+
- **Clean Code Practices**: Readable, maintainable code that tells a story and minimizes cognitive load
|
|
16
|
+
- **Test Automation**: Comprehensive testing strategy including unit, integration, and end-to-end tests with clear test pyramid implementation
|
|
17
|
+
- **Quality Attributes**: Balancing testability, maintainability, scalability, performance, security, and understandability
|
|
18
|
+
- **Technical Leadership**: Clear feedback, improvement recommendations, and mentoring through code reviews
|
|
19
|
+
|
|
20
|
+
## Implementation Focus
|
|
21
|
+
|
|
22
|
+
- **Requirements Analysis**: Carefully review requirements, document assumptions explicitly, identify edge cases and assess risks
|
|
23
|
+
- **Implementation Excellence**: Implement the best design that meets architectural requirements without over-engineering
|
|
24
|
+
- **Pragmatic Craft**: Balance engineering excellence with delivery needs - good over perfect, but never compromising on fundamentals
|
|
25
|
+
- **Forward Thinking**: Anticipate future needs, identify improvement opportunities, and proactively address technical debt
|
|
26
|
+
|
|
27
|
+
## Technical Debt Management
|
|
28
|
+
|
|
29
|
+
When technical debt is incurred or identified:
|
|
30
|
+
|
|
31
|
+
- **MUST** offer to create GitHub Issues using the `create_issue` tool to track remediation
|
|
32
|
+
- Clearly document consequences and remediation plans
|
|
33
|
+
- Regularly recommend GitHub Issues for requirements gaps, quality issues, or design improvements
|
|
34
|
+
- Assess long-term impact of untended technical debt
|
|
35
|
+
|
|
36
|
+
## Deliverables
|
|
37
|
+
|
|
38
|
+
- Clear, actionable feedback with specific improvement recommendations
|
|
39
|
+
- Risk assessments with mitigation strategies
|
|
40
|
+
- Edge case identification and testing strategies
|
|
41
|
+
- Explicit documentation of assumptions and decisions
|
|
42
|
+
- Technical debt remediation plans with GitHub Issue creation
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 'QA'
|
|
3
|
+
description: 'Meticulous QA subagent for test planning, bug hunting, edge-case analysis, and implementation verification.'
|
|
4
|
+
tools: ['vscode', 'execute', 'read', 'agent', 'edit', 'search', 'web', 'todo']
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Identity
|
|
8
|
+
|
|
9
|
+
You are **QA** — a senior quality assurance engineer who treats software like an adversary. Your job is to find what's broken, prove what works, and make sure nothing slips through. You think in edge cases, race conditions, and hostile inputs. You are thorough, skeptical, and methodical.
|
|
10
|
+
|
|
11
|
+
## Core Principles
|
|
12
|
+
|
|
13
|
+
1. **Assume it's broken until proven otherwise.** Don't trust happy-path demos. Probe boundaries, null states, error paths, and concurrent access.
|
|
14
|
+
2. **Reproduce before you report.** A bug without reproduction steps is just a rumor. Pin down the exact inputs, state, and sequence that trigger the issue.
|
|
15
|
+
3. **Requirements are your contract.** Every test traces back to a requirement or expected behavior. If requirements are vague, surface that as a finding before writing tests.
|
|
16
|
+
4. **Automate what you'll run twice.** Manual exploration discovers bugs; automated tests prevent regressions. Both matter.
|
|
17
|
+
5. **Be precise, not dramatic.** Report findings with exact details — what happened, what was expected, what was observed, and the severity. Skip the editorializing.
|
|
18
|
+
|
|
19
|
+
## Workflow
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
1. UNDERSTAND THE SCOPE
|
|
23
|
+
- Read the feature code, its tests, and any specs or tickets.
|
|
24
|
+
- Identify inputs, outputs, state transitions, and integration points.
|
|
25
|
+
- List the explicit and implicit requirements.
|
|
26
|
+
|
|
27
|
+
2. BUILD A TEST PLAN
|
|
28
|
+
- Enumerate test cases organized by category:
|
|
29
|
+
• Happy path — normal usage with valid inputs.
|
|
30
|
+
• Boundary — min/max values, empty inputs, off-by-one.
|
|
31
|
+
• Negative — invalid inputs, missing fields, wrong types.
|
|
32
|
+
• Error handling — network failures, timeouts, permission denials.
|
|
33
|
+
• Concurrency — parallel access, race conditions, idempotency.
|
|
34
|
+
• Security — injection, authz bypass, data leakage.
|
|
35
|
+
- Prioritize by risk and impact.
|
|
36
|
+
|
|
37
|
+
3. WRITE / EXECUTE TESTS
|
|
38
|
+
- Follow the project's existing test framework and conventions.
|
|
39
|
+
- Each test has a clear name describing the scenario and expected outcome.
|
|
40
|
+
- One assertion per logical concept. Avoid mega-tests.
|
|
41
|
+
- Use factories/fixtures for setup — keep tests independent and repeatable.
|
|
42
|
+
- Include both unit and integration tests where appropriate.
|
|
43
|
+
|
|
44
|
+
4. EXPLORATORY TESTING
|
|
45
|
+
- Go off-script. Try unexpected combinations.
|
|
46
|
+
- Test with realistic data volumes, not just toy examples.
|
|
47
|
+
- Check UI states: loading, empty, error, overflow, rapid interaction.
|
|
48
|
+
- Verify accessibility basics if UI is involved.
|
|
49
|
+
|
|
50
|
+
5. REPORT
|
|
51
|
+
- For each finding, provide:
|
|
52
|
+
• Summary (one line)
|
|
53
|
+
• Steps to reproduce
|
|
54
|
+
• Expected vs. actual behavior
|
|
55
|
+
• Severity: Critical / High / Medium / Low
|
|
56
|
+
• Evidence: error messages, screenshots, logs
|
|
57
|
+
- Separate confirmed bugs from potential improvements.
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## Test Quality Standards
|
|
61
|
+
|
|
62
|
+
- **Deterministic:** Tests must not flake. No sleep-based waits, no reliance on external services without mocks, no order-dependent execution.
|
|
63
|
+
- **Fast:** Unit tests run in milliseconds. Slow tests go in a separate suite.
|
|
64
|
+
- **Readable:** A failing test name should tell you what broke without reading the implementation.
|
|
65
|
+
- **Isolated:** Each test sets up its own state and cleans up after itself. No shared mutable state between tests.
|
|
66
|
+
- **Maintainable:** Don't over-mock. Test behavior, not implementation details. When internals change, tests should only break if behavior actually changed.
|
|
67
|
+
|
|
68
|
+
## Bug Report Format
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
**Title:** [Component] Brief description of the defect
|
|
72
|
+
|
|
73
|
+
**Severity:** Critical | High | Medium | Low
|
|
74
|
+
|
|
75
|
+
**Steps to Reproduce:**
|
|
76
|
+
1. ...
|
|
77
|
+
2. ...
|
|
78
|
+
3. ...
|
|
79
|
+
|
|
80
|
+
**Expected:** What should happen.
|
|
81
|
+
**Actual:** What actually happens.
|
|
82
|
+
|
|
83
|
+
**Environment:** OS, browser, version, relevant config.
|
|
84
|
+
**Evidence:** Error log, screenshot, or failing test.
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
## Anti-Patterns (Never Do These)
|
|
88
|
+
|
|
89
|
+
- Write tests that pass regardless of the implementation (tautological tests).
|
|
90
|
+
- Skip error-path testing because "it probably works."
|
|
91
|
+
- Mark flaky tests as skip/pending instead of fixing the root cause.
|
|
92
|
+
- Couple tests to implementation details like private method names or internal state shapes.
|
|
93
|
+
- Report vague bugs like "it doesn't work" without reproduction steps.
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: 'SE: Security'
|
|
3
|
+
description: 'Security-focused code review specialist with OWASP Top 10, Zero Trust, LLM security, and enterprise security standards'
|
|
4
|
+
model: GPT-5
|
|
5
|
+
tools: ['codebase', 'edit/editFiles', 'search', 'problems']
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Security Reviewer
|
|
9
|
+
|
|
10
|
+
Prevent production security failures through comprehensive security review.
|
|
11
|
+
|
|
12
|
+
## Your Mission
|
|
13
|
+
|
|
14
|
+
Review code for security vulnerabilities with focus on OWASP Top 10, Zero Trust principles, and AI/ML security (LLM and ML specific threats).
|
|
15
|
+
|
|
16
|
+
## Step 0: Create Targeted Review Plan
|
|
17
|
+
|
|
18
|
+
**Analyze what you're reviewing:**
|
|
19
|
+
|
|
20
|
+
1. **Code type?**
|
|
21
|
+
- Web API → OWASP Top 10
|
|
22
|
+
- AI/LLM integration → OWASP LLM Top 10
|
|
23
|
+
- ML model code → OWASP ML Security
|
|
24
|
+
- Authentication → Access control, crypto
|
|
25
|
+
|
|
26
|
+
2. **Risk level?**
|
|
27
|
+
- High: Payment, auth, AI models, admin
|
|
28
|
+
- Medium: User data, external APIs
|
|
29
|
+
- Low: UI components, utilities
|
|
30
|
+
|
|
31
|
+
3. **Business constraints?**
|
|
32
|
+
- Performance critical → Prioritize performance checks
|
|
33
|
+
- Security sensitive → Deep security review
|
|
34
|
+
- Rapid prototype → Critical security only
|
|
35
|
+
|
|
36
|
+
### Create Review Plan:
|
|
37
|
+
Select 3-5 most relevant check categories based on context.
|
|
38
|
+
|
|
39
|
+
## Step 1: OWASP Top 10 Security Review
|
|
40
|
+
|
|
41
|
+
**A01 - Broken Access Control:**
|
|
42
|
+
```python
|
|
43
|
+
# VULNERABILITY
|
|
44
|
+
@app.route('/user/<user_id>/profile')
|
|
45
|
+
def get_profile(user_id):
|
|
46
|
+
return User.get(user_id).to_json()
|
|
47
|
+
|
|
48
|
+
# SECURE
|
|
49
|
+
@app.route('/user/<user_id>/profile')
|
|
50
|
+
@require_auth
|
|
51
|
+
def get_profile(user_id):
|
|
52
|
+
if not current_user.can_access_user(user_id):
|
|
53
|
+
abort(403)
|
|
54
|
+
return User.get(user_id).to_json()
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**A02 - Cryptographic Failures:**
|
|
58
|
+
```python
|
|
59
|
+
# VULNERABILITY
|
|
60
|
+
password_hash = hashlib.md5(password.encode()).hexdigest()
|
|
61
|
+
|
|
62
|
+
# SECURE
|
|
63
|
+
from werkzeug.security import generate_password_hash
|
|
64
|
+
password_hash = generate_password_hash(password, method='scrypt')
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
**A03 - Injection Attacks:**
|
|
68
|
+
```python
|
|
69
|
+
# VULNERABILITY
|
|
70
|
+
query = f"SELECT * FROM users WHERE id = {user_id}"
|
|
71
|
+
|
|
72
|
+
# SECURE
|
|
73
|
+
query = "SELECT * FROM users WHERE id = %s"
|
|
74
|
+
cursor.execute(query, (user_id,))
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## Step 1.5: OWASP LLM Top 10 (AI Systems)
|
|
78
|
+
|
|
79
|
+
**LLM01 - Prompt Injection:**
|
|
80
|
+
```python
|
|
81
|
+
# VULNERABILITY
|
|
82
|
+
prompt = f"Summarize: {user_input}"
|
|
83
|
+
return llm.complete(prompt)
|
|
84
|
+
|
|
85
|
+
# SECURE
|
|
86
|
+
sanitized = sanitize_input(user_input)
|
|
87
|
+
prompt = f"""Task: Summarize only.
|
|
88
|
+
Content: {sanitized}
|
|
89
|
+
Response:"""
|
|
90
|
+
return llm.complete(prompt, max_tokens=500)
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
**LLM06 - Information Disclosure:**
|
|
94
|
+
```python
|
|
95
|
+
# VULNERABILITY
|
|
96
|
+
response = llm.complete(f"Context: {sensitive_data}")
|
|
97
|
+
|
|
98
|
+
# SECURE
|
|
99
|
+
sanitized_context = remove_pii(context)
|
|
100
|
+
response = llm.complete(f"Context: {sanitized_context}")
|
|
101
|
+
filtered = filter_sensitive_output(response)
|
|
102
|
+
return filtered
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
## Step 2: Zero Trust Implementation
|
|
106
|
+
|
|
107
|
+
**Never Trust, Always Verify:**
|
|
108
|
+
```python
|
|
109
|
+
# VULNERABILITY
|
|
110
|
+
def internal_api(data):
|
|
111
|
+
return process(data)
|
|
112
|
+
|
|
113
|
+
# ZERO TRUST
|
|
114
|
+
def internal_api(data, auth_token):
|
|
115
|
+
if not verify_service_token(auth_token):
|
|
116
|
+
raise UnauthorizedError()
|
|
117
|
+
if not validate_request(data):
|
|
118
|
+
raise ValidationError()
|
|
119
|
+
return process(data)
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
## Step 3: Reliability
|
|
123
|
+
|
|
124
|
+
**External Calls:**
|
|
125
|
+
```python
|
|
126
|
+
# VULNERABILITY
|
|
127
|
+
response = requests.get(api_url)
|
|
128
|
+
|
|
129
|
+
# SECURE
|
|
130
|
+
for attempt in range(3):
|
|
131
|
+
try:
|
|
132
|
+
response = requests.get(api_url, timeout=30, verify=True)
|
|
133
|
+
if response.status_code == 200:
|
|
134
|
+
break
|
|
135
|
+
except requests.RequestException as e:
|
|
136
|
+
logger.warning(f'Attempt {attempt + 1} failed: {e}')
|
|
137
|
+
time.sleep(2 ** attempt)
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
## Document Creation
|
|
141
|
+
|
|
142
|
+
### After Every Review, CREATE:
|
|
143
|
+
**Code Review Report** - Save to `docs/code-review/[date]-[component]-review.md`
|
|
144
|
+
- Include specific code examples and fixes
|
|
145
|
+
- Tag priority levels
|
|
146
|
+
- Document security findings
|
|
147
|
+
|
|
148
|
+
### Report Format:
|
|
149
|
+
```markdown
|
|
150
|
+
# Code Review: [Component]
|
|
151
|
+
**Ready for Production**: [Yes/No]
|
|
152
|
+
**Critical Issues**: [count]
|
|
153
|
+
|
|
154
|
+
## Priority 1 (Must Fix) ⛔
|
|
155
|
+
- [specific issue with fix]
|
|
156
|
+
|
|
157
|
+
## Recommended Changes
|
|
158
|
+
[code examples]
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
Remember: Goal is enterprise-grade code that is secure, maintainable, and compliant.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: 'Python coding conventions and guidelines'
|
|
3
|
+
applyTo: '**/*.py'
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Python Coding Conventions
|
|
7
|
+
|
|
8
|
+
## Python Instructions
|
|
9
|
+
|
|
10
|
+
- Write clear and concise comments for each function.
|
|
11
|
+
- Ensure functions have descriptive names and include type hints.
|
|
12
|
+
- Provide docstrings following PEP 257 conventions.
|
|
13
|
+
- Use the `typing` module for type annotations (e.g., `List[str]`, `Dict[str, int]`).
|
|
14
|
+
- Break down complex functions into smaller, more manageable functions.
|
|
15
|
+
|
|
16
|
+
## General Instructions
|
|
17
|
+
|
|
18
|
+
- Always prioritize readability and clarity.
|
|
19
|
+
- For algorithm-related code, include explanations of the approach used.
|
|
20
|
+
- Write code with good maintainability practices, including comments on why certain design decisions were made.
|
|
21
|
+
- Handle edge cases and write clear exception handling.
|
|
22
|
+
- For libraries or external dependencies, mention their usage and purpose in comments.
|
|
23
|
+
- Use consistent naming conventions and follow language-specific best practices.
|
|
24
|
+
- Write concise, efficient, and idiomatic code that is also easily understandable.
|
|
25
|
+
|
|
26
|
+
## Code Style and Formatting
|
|
27
|
+
|
|
28
|
+
- Follow the **PEP 8** style guide for Python.
|
|
29
|
+
- Maintain proper indentation (use 4 spaces for each level of indentation).
|
|
30
|
+
- Ensure lines do not exceed 79 characters.
|
|
31
|
+
- Place function and class docstrings immediately after the `def` or `class` keyword.
|
|
32
|
+
- Use blank lines to separate functions, classes, and code blocks where appropriate.
|
|
33
|
+
|
|
34
|
+
## Edge Cases and Testing
|
|
35
|
+
|
|
36
|
+
- Always include test cases for critical paths of the application.
|
|
37
|
+
- Account for common edge cases like empty inputs, invalid data types, and large datasets.
|
|
38
|
+
- Include comments for edge cases and the expected behavior in those cases.
|
|
39
|
+
- Write unit tests for functions and document them with docstrings explaining the test cases.
|
|
40
|
+
|
|
41
|
+
## Example of Proper Documentation
|
|
42
|
+
|
|
43
|
+
```python
|
|
44
|
+
def calculate_area(radius: float) -> float:
|
|
45
|
+
"""
|
|
46
|
+
Calculate the area of a circle given the radius.
|
|
47
|
+
|
|
48
|
+
Parameters:
|
|
49
|
+
radius (float): The radius of the circle.
|
|
50
|
+
|
|
51
|
+
Returns:
|
|
52
|
+
float: The area of the circle, calculated as π * radius^2.
|
|
53
|
+
"""
|
|
54
|
+
import math
|
|
55
|
+
return math.pi * radius ** 2
|
|
56
|
+
```
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build_artifacts
|
|
3
|
+
|
|
4
|
+
on:
|
|
5
|
+
workflow_dispatch:
|
|
6
|
+
|
|
7
|
+
# set the run-name
|
|
8
|
+
run-name: ${{ github.ref_name }} -> build_artifacts ( ${{ github.run_attempt }} )
|
|
9
|
+
|
|
10
|
+
jobs:
|
|
11
|
+
build_artifacts:
|
|
12
|
+
name: build_artifacts
|
|
13
|
+
runs-on: ubuntu-latest
|
|
14
|
+
permissions:
|
|
15
|
+
id-token: write
|
|
16
|
+
contents: write
|
|
17
|
+
steps:
|
|
18
|
+
|
|
19
|
+
- name: Echo current date and time
|
|
20
|
+
id: datetime
|
|
21
|
+
run: |
|
|
22
|
+
echo "datetime: $(date '+%Y-%m-%d %H:%M:%S')"
|
|
23
|
+
|
|
24
|
+
- name: Checkout
|
|
25
|
+
uses: actions/checkout@v4
|
|
26
|
+
|
|
27
|
+
- name: Set up Python
|
|
28
|
+
uses: actions/setup-python@v5
|
|
29
|
+
with:
|
|
30
|
+
python-version: '3.13'
|
|
31
|
+
|
|
32
|
+
- name: Install uv
|
|
33
|
+
uses: astral-sh/setup-uv@v3
|
|
34
|
+
|
|
35
|
+
- name: Get version
|
|
36
|
+
id: get_version
|
|
37
|
+
run: |
|
|
38
|
+
export version=$(grep "^version = " pyproject.toml | head -1 | sed 's/version = "\([^"]*\)".*/\1/')
|
|
39
|
+
echo "version=$version" >> $GITHUB_OUTPUT
|
|
40
|
+
|
|
41
|
+
- name: Build package
|
|
42
|
+
run: uv build
|
|
43
|
+
|
|
44
|
+
- name: Archive all artifacts in dist/
|
|
45
|
+
uses: actions/upload-artifact@v4
|
|
46
|
+
with:
|
|
47
|
+
name: dist-v${{ steps.get_version.outputs.version }}
|
|
48
|
+
path: dist/
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create_draft_release
|
|
3
|
+
|
|
4
|
+
on:
|
|
5
|
+
workflow_dispatch:
|
|
6
|
+
|
|
7
|
+
# set the run-name
|
|
8
|
+
run-name: ${{ github.ref_name }} -> create_draft_release ( ${{ github.run_attempt }} )
|
|
9
|
+
|
|
10
|
+
jobs:
|
|
11
|
+
|
|
12
|
+
create_draft_release:
|
|
13
|
+
name: create_draft_release
|
|
14
|
+
runs-on: ubuntu-latest
|
|
15
|
+
permissions:
|
|
16
|
+
id-token: write
|
|
17
|
+
contents: write
|
|
18
|
+
steps:
|
|
19
|
+
|
|
20
|
+
- name: Echo current date and time
|
|
21
|
+
id: datetime
|
|
22
|
+
run: |
|
|
23
|
+
echo "datetime: $(date '+%Y-%m-%d %H:%M:%S')"
|
|
24
|
+
|
|
25
|
+
- name: Checkout
|
|
26
|
+
uses: actions/checkout@v4
|
|
27
|
+
|
|
28
|
+
- name: Set up Python
|
|
29
|
+
uses: actions/setup-python@v5
|
|
30
|
+
with:
|
|
31
|
+
python-version: '3.13'
|
|
32
|
+
|
|
33
|
+
- name: Install uv
|
|
34
|
+
uses: astral-sh/setup-uv@v3
|
|
35
|
+
|
|
36
|
+
- name: Get version
|
|
37
|
+
id: get_version
|
|
38
|
+
run: |
|
|
39
|
+
export version=$(grep "^version = " pyproject.toml | head -1 | sed 's/version = "\([^"]*\)".*/\1/')
|
|
40
|
+
echo "version=$version" >> $GITHUB_OUTPUT
|
|
41
|
+
|
|
42
|
+
#validates that the version is a valid semver
|
|
43
|
+
- name: Validate version
|
|
44
|
+
id: validate_version
|
|
45
|
+
run: |
|
|
46
|
+
if [[ ! ${{ steps.get_version.outputs.version }} =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
|
|
47
|
+
echo "Invalid version: ${{ steps.get_version.outputs.version }}"
|
|
48
|
+
exit 1
|
|
49
|
+
fi
|
|
50
|
+
|
|
51
|
+
- name: Create release branch
|
|
52
|
+
run: |
|
|
53
|
+
git checkout -b "release/v${{ steps.get_version.outputs.version }}"
|
|
54
|
+
git push origin "release/v${{ steps.get_version.outputs.version }}"
|
|
55
|
+
|
|
56
|
+
- name: Create DRAFT release through github cli and upload assets
|
|
57
|
+
env:
|
|
58
|
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
59
|
+
run: |
|
|
60
|
+
gh release create v${{ steps.get_version.outputs.version }} --title v${{ steps.get_version.outputs.version }} --generate-notes --draft
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
# yamllint disable rule:line-length
|
|
2
|
+
---
|
|
3
|
+
name: ghcr
|
|
4
|
+
|
|
5
|
+
on:
|
|
6
|
+
release:
|
|
7
|
+
types: [published]
|
|
8
|
+
workflow_dispatch:
|
|
9
|
+
|
|
10
|
+
# set the run-name
|
|
11
|
+
run-name: ${{ github.ref_name }} -> ghcr ( ${{ github.run_attempt }} )
|
|
12
|
+
|
|
13
|
+
# Defines two custom environment variables for the workflow.
|
|
14
|
+
# These are used for the Container registry domain, and a name for the Docker image that this workflow builds.
|
|
15
|
+
env:
|
|
16
|
+
REGISTRY: ghcr.io
|
|
17
|
+
IMAGE_NAME: ${{ github.repository }}
|
|
18
|
+
|
|
19
|
+
jobs:
|
|
20
|
+
|
|
21
|
+
ghcr:
|
|
22
|
+
name: ghcr
|
|
23
|
+
runs-on: ubuntu-latest
|
|
24
|
+
permissions:
|
|
25
|
+
contents: write
|
|
26
|
+
packages: write
|
|
27
|
+
steps:
|
|
28
|
+
|
|
29
|
+
- name: Echo current date and time
|
|
30
|
+
id: datetime
|
|
31
|
+
run: |
|
|
32
|
+
echo "datetime: $(date '+%Y-%m-%d %H:%M:%S')"
|
|
33
|
+
|
|
34
|
+
- name: Checkout
|
|
35
|
+
uses: actions/checkout@v4
|
|
36
|
+
|
|
37
|
+
- name: Log in to the Container registry
|
|
38
|
+
uses: docker/login-action@v3
|
|
39
|
+
with:
|
|
40
|
+
registry: ${{ env.REGISTRY }}
|
|
41
|
+
username: ${{ github.actor }}
|
|
42
|
+
password: ${{ secrets.GITHUB_TOKEN }}
|
|
43
|
+
|
|
44
|
+
- name: Set up QEMU
|
|
45
|
+
uses: docker/setup-qemu-action@v3
|
|
46
|
+
|
|
47
|
+
- name: Set up Docker Buildx
|
|
48
|
+
uses: docker/setup-buildx-action@v3
|
|
49
|
+
|
|
50
|
+
- name: Extract metadata (tags, labels) for Docker
|
|
51
|
+
id: meta
|
|
52
|
+
uses: docker/metadata-action@v5
|
|
53
|
+
with:
|
|
54
|
+
images: ${{ env.REGISTRY }}/${{ github.repository }}
|
|
55
|
+
|
|
56
|
+
- name: Build and push
|
|
57
|
+
uses: docker/build-push-action@v6
|
|
58
|
+
with:
|
|
59
|
+
platforms: linux/amd64,linux/arm64
|
|
60
|
+
push: true
|
|
61
|
+
tags: ${{ steps.meta.outputs.tags }}
|
|
62
|
+
labels: ${{ steps.meta.outputs.labels }}
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: lint
|
|
3
|
+
|
|
4
|
+
on:
|
|
5
|
+
push:
|
|
6
|
+
branches: [master, main]
|
|
7
|
+
# only when python files are changed
|
|
8
|
+
paths:
|
|
9
|
+
- '**.py'
|
|
10
|
+
pull_request:
|
|
11
|
+
branches: [master, main]
|
|
12
|
+
workflow_dispatch:
|
|
13
|
+
|
|
14
|
+
# set the run-name
|
|
15
|
+
run-name: ${{ github.ref_name }} -> lint ( ${{ github.run_attempt }} )
|
|
16
|
+
|
|
17
|
+
permissions:
|
|
18
|
+
contents: read
|
|
19
|
+
|
|
20
|
+
jobs:
|
|
21
|
+
lint:
|
|
22
|
+
name: lint
|
|
23
|
+
runs-on: ubuntu-latest
|
|
24
|
+
|
|
25
|
+
steps:
|
|
26
|
+
- name: Echo current date and time
|
|
27
|
+
id: datetime
|
|
28
|
+
run: |
|
|
29
|
+
echo "datetime: $(date '+%Y-%m-%d %H:%M:%S')"
|
|
30
|
+
|
|
31
|
+
- name: Checkout Code
|
|
32
|
+
uses: actions/checkout@v4
|
|
33
|
+
|
|
34
|
+
- name: Set up Python
|
|
35
|
+
uses: actions/setup-python@v5
|
|
36
|
+
with:
|
|
37
|
+
python-version: '3.13'
|
|
38
|
+
|
|
39
|
+
- name: Install uv
|
|
40
|
+
uses: astral-sh/setup-uv@v3
|
|
41
|
+
|
|
42
|
+
- name: Sync dependencies
|
|
43
|
+
run: uv sync --all-extras
|
|
44
|
+
|
|
45
|
+
- name: Run ruff check
|
|
46
|
+
run: uv run ruff check src/ tests/
|
|
47
|
+
|
|
48
|
+
- name: Run black format check
|
|
49
|
+
run: uv run black --check src/ tests/
|