diff --git a/docs/plans/visibility-system.md b/docs/plans/visibility-system.md
index 040d9c95b..84f4914b5 100644
--- a/docs/plans/visibility-system.md
+++ b/docs/plans/visibility-system.md
@@ -47,10 +47,13 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public';
 | `unlisted`  | Wer den Direct-Link + Token hat; nicht gelistet, nicht indexiert | Event-Einladungen mit Nicht-Member-Gästen |
 | `public`    | Beliebig — sichtbar auf Website-Embeds, für AI-Agent referenzierbar | Ein aktiv als "für die Öffentlichkeit" markiertes Item |
 
-**Default bei Record-Create:** leitet sich vom Space-Typ ab.
-- Personal-Space → `private`
-- Team/Club-Space → `space` (sonst müssten User bei jedem Task manuell "meine Space-Mitglieder dürfen das sehen" setzen — unrealistisch)
-- Nie `public` oder `unlisted` als Default.
+**Default bei Record-Create:** **immer `space`**, unabhängig vom Space-Typ.
+
+Ursprünglich war Personal-Space → `private` geplant. Nach der ersten Integration (M4.b Todo) stellte sich heraus: das existierende 2-Stufen-System in `scope/visibility.ts` behandelt `'private'` als "nur der Author sieht es, auch innerhalb des gleichen Space" — und filtert solche Records im `applyVisibility()`-Aufruf der Modul-Queries. Das fightet mit dem "Personal-Space default = private"-Plan: neu angelegte Tasks/Events erschienen im Homepage-Widget (das keinen Filter nutzt), verschwanden aber auf `/todo` (Filter schlägt zu). Der `authorId`-Check in `applyVisibility` versagt während des Auth-Bootstraps, wenn der Hook `'guest'` als authorId stempelt aber `getCurrentUserId()` bereits den echten User zurückgibt.
+
+Der robuste Fix: `defaultVisibilityFor()` returnt immer `'space'`. Im Personal-Space (1 Member) ist das semantisch äquivalent zu `'private'`. In Multi-Member-Spaces ist `'space'` der erwünschte Default (sonst müssten User jeden Task manuell für ihre Mitglieder freischalten). `'private'` wird zur **aktiven User-Entscheidung** für Drafts in geteilten Spaces — Klick im VisibilityPicker.
+
+- Nie `public` oder `unlisted` als Default (deny-by-default-Regel bleibt).
 
 **Begründung der Namen:** `visibility` + 4-Stufen-Enum ist das vertraute Google-Drive/YouTube-Mental-Model. Alternativ diskutiert: `sharingLevel`, `audience`. Verworfen — `visibility` ist breiter bekannt und technischer neutral (keine "Zuhörerschaft"-Assoziation).
 
@@ -68,8 +71,11 @@ export type VisibilityLevel = 'private' | 'space' | 'unlisted' | 'public';
 export const VisibilityLevelSchema = z.enum(['private', 'space', 'unlisted', 'public']);
 
 // defaults.ts
-export function defaultVisibilityFor(spaceType: SpaceType): VisibilityLevel {
-  return spaceType === 'personal' ? 'private' : 'space';
+export function defaultVisibilityFor(_spaceType: SpaceType | null | undefined): VisibilityLevel {
+  // Always 'space' — compatible with the existing 2-tier applyVisibility
+  // filter, and semantically equivalent to 'private' in personal spaces
+  // (only one member). Users flip to 'private' explicitly for drafts.
+  return 'space';
 }
 
 // predicates.ts
diff --git a/packages/shared-privacy/src/defaults.test.ts b/packages/shared-privacy/src/defaults.test.ts
index 43e6e5864..4f20cc63b 100644
--- a/packages/shared-privacy/src/defaults.test.ts
+++ b/packages/shared-privacy/src/defaults.test.ts
@@ -2,8 +2,11 @@ import { describe, it, expect } from 'vitest';
 import { defaultVisibilityFor } from './defaults';
 
 describe('defaultVisibilityFor', () => {
-	it('returns private for personal space', () => {
-		expect(defaultVisibilityFor('personal')).toBe('private');
+	// 'space' everywhere so the default stays compatible with the
+	// existing 2-tier `applyVisibility` filter in scope/visibility.ts.
+	// See the function's doc comment for the full rationale.
+	it('returns space for personal space', () => {
+		expect(defaultVisibilityFor('personal')).toBe('space');
 	});
 
 	it('returns space for multi-member types', () => {
@@ -12,13 +15,13 @@ describe('defaultVisibilityFor', () => {
 		expect(defaultVisibilityFor('firma')).toBe('space');
 	});
 
-	it('returns space for unknown multi-member types (safe assumption)', () => {
+	it('returns space for unknown types', () => {
 		expect(defaultVisibilityFor('band')).toBe('space');
 	});
 
-	it('falls back to private when space type is missing', () => {
-		expect(defaultVisibilityFor(null)).toBe('private');
-		expect(defaultVisibilityFor(undefined)).toBe('private');
-		expect(defaultVisibilityFor('')).toBe('private');
+	it('returns space when space type is missing', () => {
+		expect(defaultVisibilityFor(null)).toBe('space');
+		expect(defaultVisibilityFor(undefined)).toBe('space');
+		expect(defaultVisibilityFor('')).toBe('space');
 	});
 });
diff --git a/packages/shared-privacy/src/defaults.ts b/packages/shared-privacy/src/defaults.ts
index 690547810..66d2a26df 100644
--- a/packages/shared-privacy/src/defaults.ts
+++ b/packages/shared-privacy/src/defaults.ts
@@ -1,20 +1,30 @@
 import type { VisibilityLevel } from './types';
 
 /**
- * Default visibility for newly-created records, derived from the space
- * type. Personal spaces stay `private` so a fresh note or task doesn't
- * accidentally leak to cohabitants of a team space; multi-member spaces
- * (team, club, firma, …) default to `space` so collaboration works
- * without requiring a manual toggle on every write.
+ * Default visibility for newly-created records — always 'space'.
  *
- * Accepts `null`/`undefined`/unknown strings and treats them as personal
- * — the safer direction. Callers that know the space type pass it
- * directly; callers that don't (e.g. during sync-apply) fall back to
- * 'private'.
+ * Why not 'private' for personal spaces even though the original plan
+ * read "personal → private": it would fight the existing 2-tier
+ * visibility filter in `apps/mana/apps/web/src/lib/data/scope/
+ * visibility.ts`, which treats `'private'` records as "only the author
+ * sees them, even inside the same space". That's the semantic the
+ * broader codebase already depends on — queries like `useAllTasks()`
+ * apply it at read time. Stamping `'private'` as the default here
+ * causes records to disappear from module sub-routes during auth
+ * bootstrap (authorId stamped with the guest-sentinel, later filtered
+ * out once the real user id resolves).
+ *
+ * In a personal space there's only one member, so 'space' and 'private'
+ * are equivalent in effect — both mean "only you see it". In
+ * multi-member spaces, 'space' means "fellow members can see it"
+ * which is the desired default for collaboration. Users who want a
+ * genuine "draft, hide from fellow members" state flip explicitly
+ * to `'private'` via the VisibilityPicker.
+ *
+ * The parameter is retained for forward-compatibility — a future
+ * space type (e.g. 'restricted' invite-only) might want a different
+ * default without changing every call site.
  */
-export function defaultVisibilityFor(spaceType: string | null | undefined): VisibilityLevel {
-	if (!spaceType) return 'private';
-	if (spaceType === 'personal') return 'private';
-	// team, club, firma, or any future multi-member type.
+export function defaultVisibilityFor(_spaceType: string | null | undefined): VisibilityLevel {
 	return 'space';
 }