F-002 fix: Remove secrets and externalize config

This commit is contained in:
rikrdo
2026-05-25 08:00:05 +02:00
parent d3a558352d
commit 3d41579ad3
58 changed files with 1192807 additions and 52 deletions

47
spec/sdd/architecture.md Normal file
View File

@@ -0,0 +1,47 @@
# Architecture Overview — Legacy PHP Product Module
## Context
This repo holds one legacy PHP module copied from production.
The module helps product staff create products and generate SEO text.
The module also runs one batch worker that updates OpenCart product descriptions.
Current raw source path was `project/new`.
Target stable path is `project/web/index/new`.
SQL dump target path is `project/sql/db-25052026.sql`.
## Main flows
1. User opens product form.
2. Form reads OpenCart data from MariaDB.
3. User can open AI helper page for one product text.
4. Bulk page writes product ids into `oc_product_queue`.
5. CLI worker reads queue, calls OpenAI, updates `oc_product_description`.
## Constraints
- Keep legacy behavior unchanged in layout and config features.
- Preserve file contents during move unless config externalization requires value lookup changes.
- Keep evidence in repo for each design change.
- Do not redesign auth or deploy in these features.
## System view
```mermaid
graph TD
U[Backoffice user] --> F[Legacy PHP web module]
F --> DB[(MariaDB / OpenCart)]
F --> Q[oc_product_queue]
W[worker_bulk.php CLI worker] --> Q
W --> AI[OpenAI API]
W --> DB
```
## Files and responsibilities
- `bootstrap.php`: shared local config loader and DB helper
- `config/local.example.php`: versioned config shape
- `config/local.php`: ignored local values file
- `index.php`: manual product create form
- `describe.php`: one-shot AI description helper
- `productos_bulk_update.php`: queue intake and worker log viewer
- `productos_modificados.php`: review processed items
- `worker_bulk.php`: batch generator and DB updater
- `inc/*`: shared layout, prompts, AJAX helpers
- `db/conn.php`: shared DB connection for web pages
- `logs/*`: runtime debug output from worker and AI calls

View File

@@ -0,0 +1,33 @@
# Component: Bulk SEO worker
## Responsibility
Read product ids from queue.
Call OpenAI with EN and ES prompts.
Clean output.
Update OpenCart product description fields.
Write processing logs.
## Interfaces
- Input:
- CLI run of `worker_bulk.php`
- rows from `oc_product_queue`
- prompt files `inc/prompt_en.md` and `inc/prompt_es.md`
- Output:
- updates in `oc_product_description`
- status fields in `oc_product_queue`
- log files under `logs/`
## Dependencies
- MariaDB/MySQL
- OpenAI Chat Completions API
- local prompt markdown files
## Limits
- No secret management yet.
- No retry queue store outside DB.
- No metrics or structured logs.
## Success criteria
- [ ] Worker path is documented
- [ ] Queue and DB side effects are known
- [ ] Log location is explicit in design docs

View File

@@ -0,0 +1,24 @@
# Component: Development data baseline
## Responsibility
Provide one local SQL dump so maintainers can inspect schema and seed dev database.
## Interfaces
- Input:
- SQL import command run by maintainer
- Output:
- local MariaDB database with OpenCart and custom tables
## Dependencies
- `project/sql/db-25052026.sql`
- local MariaDB/MySQL server
## Limits
- Dump may contain production-like data.
- Dump is large.
- Dump is not safe for public sharing without review.
## Success criteria
- [ ] Dump path is stable and explicit
- [ ] Design docs call it dev baseline only
- [ ] Move does not alter dump content

View File

@@ -0,0 +1,30 @@
# Component: Legacy config loader
## Responsibility
Load local configuration for the legacy PHP module.
Expose helper access for DB, OpenAI, URLs, endpoints, and path values.
Provide one DB connection factory used by web pages and worker.
## Interfaces
- Input:
- `config/local.php` if present
- fallback `config/local.example.php` for shape and safe defaults
- Output:
- config access helpers
- mysqli connection helper
- normalized path values for logs and routes
## Dependencies
- PHP array config files
- `mysqli`
- module root path
## Limits
- Does not manage secret rotation.
- Does not validate remote credentials.
- Does not redesign auth or downstream business logic.
## Success criteria
- [ ] No tracked PHP file contains hard-coded DB or OpenAI secrets
- [ ] Entry points use shared config helper
- [ ] Local setup path is documented

View File

@@ -0,0 +1,32 @@
# Component: Legacy web module
## Responsibility
Serve old PHP pages for product create and product SEO work.
Render HTML.
Read OpenCart data.
Write queue rows for batch processing.
## Interfaces
- Input:
- browser GET and POST requests
- session state from external login flow
- Output:
- HTML pages
- inserts into `oc_product_queue`
- writes brand rows and URL alias rows
## Dependencies
- `db/conn.php`
- `inc/header.php`, `inc/footer.php`
- OpenCart tables
- external `success.php` and `login.php` outside repo
## Limits
- Does not own authentication.
- Does not own final product creation endpoint.
- Uses hard-coded config today.
## Success criteria
- [ ] Module files live under stable repo path
- [ ] Relative module structure stays intact
- [ ] Pages can still be reviewed as one legacy unit

View File

@@ -0,0 +1,33 @@
# ADR-001: Store legacy app under project web path
## Status
Accepted
## Context
Legacy PHP code was copied into `project/new`.
That path does not explain app role.
SQL dump also sits beside code in `project/` root.
We need stable layout before deeper refactor.
## Decision
Store legacy web code under `project/web/index/new`.
Store SQL dump under `project/sql/db-25052026.sql`.
Keep internal legacy file tree unchanged inside module.
Do not refactor code in same step.
## Consequences
- Good:
- repo layout shows what is web code and what is data
- ARNES design docs can point to stable paths
- future config and secret cleanup gets easier
- Bad:
- move may require path-aware follow-up in later features
- repo still contains legacy secrets until later cleanup
## Alternatives considered
1. Keep code in `project/new` - rejected because path is temporary and vague.
2. Move code to `project/app` - rejected because this is web module, not service code.
3. Refactor layout and code now - rejected because scope would grow too much.
## Date
2026-05-25

View File

@@ -0,0 +1,33 @@
# ADR-002: Use local config loader for legacy module
## Status
Accepted
## Context
Security gate for F-001 failed.
Legacy PHP files still hold DB credentials, OpenAI keys, and production-coupled URLs.
The module needs one small config mechanism without large refactor.
## Decision
Add `bootstrap.php` to the legacy module root.
Load config from `config/local.php` with fallback to `config/local.example.php`.
Expose shared helper functions for config lookup and DB connection.
Update web pages and worker to read DB, OpenAI, route, and URL values through this helper.
Ignore `config/local.php` in git.
## Consequences
- Good:
- secrets leave tracked PHP source files
- one config shape is reused by web pages and worker
- local setup becomes explicit
- Bad:
- module still depends on local file management
- fallback example config can still fail at runtime until maintainer fills real values
## Alternatives considered
1. Use environment variables only - rejected because this legacy module already expects file-based setup.
2. Keep secrets in PHP constants - rejected because tracked source would still hold sensitive values.
3. Full framework migration - rejected because scope is too large for this fix.
## Date
2026-05-25