first pass at the newspaper builder

.aidlc/tools/data/memory-seed/phases/construction.md

@@ -0,0 +1,30 @@
+# Construction Phase Guardrails
+
+These rules apply to every stage whose `phase: construction` declaration
+imports them as the matching phase rule.
+
+## Code Completeness
+
+- Generate complete, runnable files — no partial implementations, no placeholder stubs unless explicitly marked TODO with a rationale
+- Every generated module must be independently executable or clearly document its dependencies
+- Do not leave unresolved import errors, missing type definitions, or broken references
+
+## Error Handling
+
+- Always include error handling at integration boundaries (API calls, database operations, file I/O, external services)
+- Errors must be surfaced to the caller or logged — silent failures are not acceptable
+- Distinguish between recoverable errors (retry/fallback) and fatal errors (fail fast)
+
+## Testing Standards
+
+- Test files must cover the happy path and at least two error/edge cases
+- Tests must be runnable without manual setup beyond documented prerequisites
+- Do not generate tests that always pass regardless of implementation (e.g., `assert True`)
+
+## Security
+
+- Never hardcode credentials, API keys, or secrets — use environment variables or a secrets manager
+- Validate and sanitize all inputs at system boundaries
+- Flag any code that bypasses authentication or authorization checks
+
+## Corrections

.aidlc/tools/data/memory-seed/phases/ideation.md

@@ -0,0 +1,30 @@
+# Ideation Phase Guardrails
+
+These rules apply to every stage whose `phase: ideation` declaration
+imports them as the matching phase rule.
+
+## Focus
+
+- Prioritize user needs and problem definition before proposing solutions
+- Keep ideation artifacts at the problem/opportunity level — no implementation details
+- Explore the problem space broadly before narrowing to solutions
+
+## Evidence Standards
+
+- Market research claims require citations or explicit source attribution
+- Feasibility estimates must be conservative — flag assumptions clearly
+- Do not present speculation as fact; label uncertain claims as "hypothesis" or "assumption"
+
+## Scope Discipline
+
+- No implementation details (architecture, tech stack, code) in ideation artifacts
+- Do not carry forward scope decisions that have not been explicitly approved
+- If a feasibility concern would block progress, surface it early rather than glossing over it
+
+## Output Quality
+
+- All ideation artifacts must be readable by non-technical stakeholders
+- Avoid jargon unless defined in a glossary
+- Success metrics must be measurable — avoid vague outcomes like "improved performance"
+
+## Corrections

.aidlc/tools/data/memory-seed/phases/inception.md

@@ -0,0 +1,29 @@
+# Inception Phase Guardrails
+
+These rules apply to every stage whose `phase: inception` declaration
+imports them as the matching phase rule.
+
+## Requirements Quality
+
+- Requirements must be testable and verifiable — each requirement must have a clear pass/fail criterion
+- Avoid ambiguous language ("fast", "easy", "user-friendly") unless paired with a measurable threshold
+- Never carry forward unresolved contradictions between requirements; surface and resolve them explicitly
+
+## Architecture Standards
+
+- Architecture decisions require trade-off analysis — document at least two alternatives considered
+- All ADRs must include: Context, Decision, Consequences, and Alternatives Rejected
+- Security and compliance implications must be addressed for every major architectural decision
+
+## User Stories
+
+- User stories follow Given/When/Then (BDD) format for acceptance criteria
+- Each story must identify the actor, the action, and the business value
+- Stories must be independently testable — avoid stories that only make sense in sequence
+
+## Traceability
+
+- Every requirement must trace back to an ideation artifact (intent, feasibility, or scope)
+- Do not introduce new requirements in inception without documenting their origin
+
+## Corrections

.aidlc/tools/data/memory-seed/phases/operation.md

@@ -0,0 +1,29 @@
+# Operation Phase Guardrails
+
+These rules apply to every stage whose `phase: operation` declaration
+imports them as the matching phase rule.
+
+## Infrastructure Safety
+
+- Infrastructure changes require security review — document the security implications of every change
+- Never remove or bypass existing security controls without explicit approval and documented rationale
+- Changes to IAM roles, network policies, or encryption settings must include a risk assessment
+
+## Deployment Procedures
+
+- All deployment procedures must include rollback steps — document how to reverse every change
+- Deployments to production must have a defined smoke test or health check to verify success
+- Blue/green or canary strategies must document traffic-shifting criteria and abort conditions
+
+## Observability
+
+- SLOs must be quantified with specific percentages and time windows (e.g., "99.9% availability over a 30-day rolling window")
+- Alerting thresholds must be set below SLO breach to allow time for remediation
+- Every new service or component must have at least one health metric and one error rate metric
+
+## Incident Response
+
+- Runbooks must include escalation paths and contact information
+- Post-incident reviews are required for any P1/P2 incident — document timeline, root cause, and prevention
+
+## Corrections