docs: reorganize tree, restore architecture + research from archive, add Phase 0 reports
Active docs/ was stub scaffolding while the real docs sat in docs/_archive/. Restore and correct them, and record the Phase 0 work. - docs/architecture/current.md: verified system map (from archived SYSTEM_OVERVIEW, 9 corrections against code). - docs/research/competitors.md: sourced competitor analysis (from archived PRODUCT_RESEARCH, feature matrix corrected). - docs/decisions/ADR-002-job-application-model.md: the Job/JobApplication split. - docs/application-discovery-report.md, docs/implementation-roadmap.md, docs/phase-0-foundation-report.md, docs/career-workspace-branch-assessment.md. - Remove 10 zero-byte placeholder files that advertised content that never existed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,105 @@
|
||||
# Product Principles
|
||||
|
||||
## Purpose
|
||||
|
||||
Defines the principles that guide product decisions.
|
||||
|
||||
---
|
||||
|
||||
# Principle 1
|
||||
|
||||
## Job Tracking Comes First
|
||||
|
||||
Jobjakt exists primarily to help users manage their job search.
|
||||
|
||||
Every major decision should support:
|
||||
|
||||
- Finding jobs.
|
||||
- Applying efficiently.
|
||||
- Tracking progress.
|
||||
- Improving outcomes.
|
||||
|
||||
---
|
||||
|
||||
# Principle 2
|
||||
|
||||
## Career Data Is the Foundation
|
||||
|
||||
Users should maintain one professional identity.
|
||||
|
||||
The application should avoid:
|
||||
|
||||
- Multiple disconnected profiles.
|
||||
- Re-entering information.
|
||||
- Duplicating career history.
|
||||
|
||||
---
|
||||
|
||||
# Principle 3
|
||||
|
||||
## AI Assists, Humans Decide
|
||||
|
||||
AI should:
|
||||
|
||||
- Suggest.
|
||||
- Improve.
|
||||
- Analyse.
|
||||
- Accelerate.
|
||||
|
||||
AI should not:
|
||||
|
||||
- Replace user judgement.
|
||||
- Modify facts silently.
|
||||
- Invent experience.
|
||||
|
||||
---
|
||||
|
||||
# Principle 4
|
||||
|
||||
## Simplicity Over Complexity
|
||||
|
||||
Powerful features should remain approachable.
|
||||
|
||||
Avoid:
|
||||
|
||||
- Complex workflows.
|
||||
- Excessive configuration.
|
||||
- Feature overload.
|
||||
|
||||
---
|
||||
|
||||
# Principle 5
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
Show users what they need when they need it.
|
||||
|
||||
Example:
|
||||
|
||||
New users:
|
||||
|
||||
Simple CV creation.
|
||||
|
||||
Advanced users:
|
||||
|
||||
Custom themes, AI tools, detailed controls.
|
||||
|
||||
---
|
||||
|
||||
# Principle 6
|
||||
|
||||
## Quality Over Quantity
|
||||
|
||||
A small number of excellent features is better than many unfinished features.
|
||||
|
||||
---
|
||||
|
||||
# Principle 7
|
||||
|
||||
## SaaS Ready, Not SaaS First
|
||||
|
||||
Architecture should allow future growth.
|
||||
|
||||
However:
|
||||
|
||||
Do not sacrifice user experience today for hypothetical future requirements.
|
||||
Reference in New Issue
Block a user