amr/passepartout
1
0
Fork 0
Code Issues 15 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

REFAC: Added emacs-nox to Dockerfile and updated GTD mandate in standards

Browse Source
This commit is contained in:
Amr Gharbeia
2026-04-13 21:20:56 -04:00
parent 9c2d453656
commit b1656d0835
3 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
Dockerfile
View File

@@ -19,6 +19,7 @@ RUN apt-get update && apt-get install -y \
python3 \ python3 \
python3-pip \ python3-pip \
python3-venv \ python3-venv \
emacs-nox \
&& rm -rf /var/lib/apt/lists/* && rm -rf /var/lib/apt/lists/*
# 2. Setup Playwright (High-Fidelity Browsing) # 2. Setup Playwright (High-Fidelity Browsing)

1
literate/setup.org
View File

@@ -36,6 +36,7 @@ RUN apt-get update && apt-get install -y \
python3 \ python3 \
python3-pip \ python3-pip \
python3-venv \ python3-venv \
emacs-nox \
&& rm -rf /var/lib/apt/lists/* && rm -rf /var/lib/apt/lists/*
# 2. Setup Playwright (High-Fidelity Browsing) # 2. Setup Playwright (High-Fidelity Browsing)

2
skills/org-skill-engineering-standards.org
View File

@@ -31,7 +31,7 @@ Major architectural shifts or complex refactors require a formal implementation
You are strictly forbidden from drafting a plan or requesting formal approval in the same conversational turn that you propose an initial strategy or begin file discovery. You MUST propose your strategy in plain text, explicitly state "Waiting for user feedback," and yield the turn. You may only proceed to draft the `.md` plan after the user explicitly replies with agreement. You are strictly forbidden from drafting a plan or requesting formal approval in the same conversational turn that you propose an initial strategy or begin file discovery. You MUST propose your strategy in plain text, explicitly state "Waiting for user feedback," and yield the turn. You may only proceed to draft the `.md` plan after the user explicitly replies with agreement.
** 7. GTD Synchronization (Roadmap Integrity) ** 7. GTD Synchronization (Roadmap Integrity)
You are strictly forbidden from considering a task complete without updating `gtd.org`. Every major architectural shift, feature implementation, or refactor MUST be recorded in the project roadmap to ensure technical transparency and historical auditability. You are strictly forbidden from considering a task complete without updating `gtd.org`. Every major architectural shift, feature implementation, or refactor MUST be recorded in the project roadmap to ensure technical transparency and historical auditability. When updating `gtd.org`, you MUST NEVER use checkboxes (`[ ]`) for sub-tasks; always use hierarchical sub-TODO headlines.
** 8. Configuration Externalization (Environment-Driven) ** 8. Configuration Externalization (Environment-Driven)
Source code MUST be strictly free of hardcoded configuration values (e.g., ports, rhythms, timeouts). All such values must be extracted to the environment (via `.env`) and documented in `.env.example`. This ensures portability and security. Source code MUST be strictly free of hardcoded configuration values (e.g., ports, rhythms, timeouts). All such values must be extracted to the environment (via `.env`) and documented in `.env.example`. This ensures portability and security.