make rewirte start

specification.txt

@@ -0,0 +1,168 @@
+SPECIFICATION (German)
+
+Project role
+- This is an online contact directory / personal archive, not a transaction
+  ledger. Its main job is to store and share structured information about
+  people and their related items under controlled access.
+
+Core concepts
+- Account (Login identity)
+  * One account is permanently tied to exactly one email address.
+  * Each email address has its own password.
+  * Different accounts can have different rights.
+  * An account is the login boundary, not the data owner in every case.
+
+- Person
+  * A person is the central real-world entity.
+  * One person can be linked to multiple email addresses / accounts but every account /e-mail can only be linke to oner person.
+  * A person is not owned by any single account.
+
+- Article
+  * Every person has articles.
+  * Articles exist in different article types.
+  * Article visibility is not global.
+  * Articles are only visible to people who hold the required rights and/or
+    belong to the required group(s).
+
+- Article types
+  * Examples of article types:
+    - Contact details
+    - Notes
+    - Profile text
+    - Documents
+    - Links
+    - Phone numbers
+    - Addresses
+    - Social profiles
+  * The set of article types is fixed for the implementation, but the system
+    treats them as distinct, named categories.
+
+- Groups
+  * Groups are person-dependent.
+  * Groups are NOT email-dependent.
+  * A group describes a set of persons.
+  * Group membership follows the person, regardless of which account or email
+    is used to access the system.
+
+- Rights
+  * Rights are fixed, named capabilities.
+  * Rights control what can be seen, created, edited, or removed.
+  * Rights are used together with group membership to decide access.
+
+Relationships
+- Account <-> email
+  * One account, one email address, fixed binding.
+- Email <-> password
+  * Each email has its own password.
+- Person <-> accounts / emails
+  * One person may relate to several emails/accounts.
+- Person <-> groups
+  * Groups are built around persons.
+- Person <-> articles
+  * A person owns articles of various types.
+- Articles <-> readers
+  * Reading and other actions depend on rights.
+  * Reading can also depend on group membership.
+- Groups <-> persons
+  * Membership is defined by persons, not by accounts.
+
+Access model
+- Visibility rule
+  * An article is shown only if the requesting party has the required right
+    AND is allowed by the relevant group constraints.
+  * If either condition is not met, the article is not visible.
+- Purpose of the rule
+  * Some articles are private.
+  * Some articles are shared only with selected persons or groups.
+  * Group-based visibility is independent from email/account identity.
+
+Account scope
+- Login
+  * Accounts are used to authenticate a user.
+  * Authentication is tied to an email address and password.
+- Rights assignment
+  * Different accounts can be granted different rights.
+  * Rights are assigned at account level or in relation to persons/groups,
+    depending on the access rule for the article.
+
+Person scope
+- Data ownership
+  * A person is the owner of their own articles.
+  * A person can have multiple linked accounts/emails.
+- Shared context
+  * Other parties may access articles only through the rights/group model.
+
+Groups and persons
+- Membership
+  * Groups contain persons.
+  * Group membership does not depend on the email used for login.
+- Example interpretation
+  * If a person belongs to a group, then that group relation follows the
+    person, not a specific email account.
+
+Article model
+- Each article has:
+  * An article type
+  * Content belonging to that type
+  * An owner person context
+  * Access rules based on rights and group membership
+- Article types are distinct categories, not free text, so that access can be
+  handled per type in a structured way.
+
+Security and privacy goals
+- Private by default where appropriate
+  * Not everything is publicly visible.
+- Controlled sharing
+  * Sharing happens via rights and groups, not via open access.
+- Person-centric sharing
+  * Visibility follows persons and groups, not only the account that logs in.
+- Separation of concerns
+  * Login (account/email/password) is separate from data ownership (person).
+  * This allows one person to be reachable through several emails without
+    merging all content into one account identity.
+
+Functional expectations
+- Account management
+  * Create account for an email address with a password.
+  * The email address is fixed for that account.
+- Person management
+  * Represent persons independently of a single account.
+  * Link multiple emails/accounts to one person where needed.
+- Article management
+  * Create, view, edit, and remove articles for a person.
+  * Store articles by type.
+  * Enforce visibility by rights and group membership.
+- Group management
+  * Groups are defined around persons.
+  * Membership is used for visibility/access decisions.
+- Rights handling
+  * Rights decide what is allowed for an account/requesting party.
+  * Rights work together with group-based visibility rules.
+
+Non-goals for this version
+- This is not a payment system.
+- This is not a transaction ledger.
+- This is not primarily an account-consumption platform; accounts exist for
+  login and rights, but persons and their articles are the main content.
+
+Level of detail required from the specification
+- Account model
+  * Fixed email per account.
+  * Password per email.
+  * Different rights per account.
+- Person model
+  * Persons as first-class entities.
+  * Support for multiple emails per person.
+- Article model
+  * Article types.
+  * Ownership context.
+  * Rights/group-based visibility.
+- Group model
+  * Person-dependent groups.
+  * No email-dependent groups.
+- Access behavior
+  * Explicit visibility rules.
+  * No open global visibility for restricted articles.
+
+This specification intentionally describes what the system is and what rules
+it follows, so that later implementation matches the intended model exactly.