@amityco/social-plus-vise 1.4.6 → 1.5.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amityco/social-plus-vise",
-  "version": "1.4.6",
+  "version": "1.5.0",
   "description": "Skill-guided deterministic CLI for social.plus SDK integration assistance.",
   "license": "SEE LICENSE IN LICENSE",
   "type": "module",

package/rules/feed.yaml

@@ -68,6 +68,28 @@
         }
       }
     },
+    {
+      "id": "ios.feed.source-used",
+      "version": 1,
+      "title": "iOS feed integration must use SDK post APIs",
+      "severity": "warning",
+      "rationale": "A community/profile-only SDK integration is not an add-feed implementation. Feed surfaces must query or create SDK posts and render SDK post data.",
+      "applies_when": {
+        "platforms": ["ios"],
+        "outcomes": ["add-feed", "validate-setup"]
+      },
+      "enforcement": {
+        "deterministic": [
+          { "check": "validator-finding-absent", "finding_rule_id": "ios.feed.source-used" }
+        ],
+        "attestation": {
+          "allowed": false,
+          "host_agent_min_confidence": "high",
+          "human_allowed": false,
+          "evidence_required": []
+        }
+      }
+    },
     {
       "id": "typescript.feed.target.literal",
       "version": 1,
@@ -1547,9 +1569,9 @@
       "id": "typescript.feed.target-type-explicit",
       "version": 1,
       "symbol_anchored": {"platform":"typescript","basis":"pattern"},
-      "title": "Explicit targetType for TypeScript createPost calls must not be hardcoded to COMMUNITY",
+      "title": "TypeScript createPost targetType must be a valid, bound write target",
       "severity": "warning",
-      "rationale": "TypeScript feed targets must be passed dynamically (e.g. from props or state), not hardcoded as AmityPostTargetType.COMMUNITY.",
+      "rationale": "TypeScript createPost targets must resolve to a valid SDK write target (user or community) with a targetId from props/state/auth/route, never a global aggregate feed target.",
       "applies_when": {
         "platforms": [
           "typescript"
@@ -1573,7 +1595,7 @@
           "evidence_required": [
             {
               "field": "target_type_rationale",
-              "description": "Reason why this composer is hardcoded to a specific target type.",
+              "description": "Reason why this composer uses this targetType/targetId binding.",
               "upload_policy": "upload-with-consent"
             }
           ]
@@ -1584,9 +1606,9 @@
       "id": "react-native.feed.target-type-explicit",
       "version": 1,
       "symbol_anchored": {"platform":"react-native","basis":"pattern"},
-      "title": "Explicit targetType for React Native createPost calls must not be hardcoded to COMMUNITY",
+      "title": "React Native createPost targetType must be a valid, bound write target",
       "severity": "warning",
-      "rationale": "React Native feed targets must be passed dynamically (e.g. from props or state), not hardcoded as AmityPostTargetType.COMMUNITY.",
+      "rationale": "React Native createPost targets must resolve to a valid SDK write target (user or community) with a targetId from props/state/auth/route, never a global aggregate feed target.",
       "applies_when": {
         "platforms": [
           "react-native"
@@ -1610,7 +1632,7 @@
           "evidence_required": [
             {
               "field": "target_type_rationale",
-              "description": "Reason why this composer is hardcoded to a specific target type.",
+              "description": "Reason why this composer uses this targetType/targetId binding.",
               "upload_policy": "upload-with-consent"
             }
           ]
@@ -1621,9 +1643,9 @@
       "id": "android.feed.target-type-explicit",
       "version": 1,
       "symbol_anchored": {"platform":"android","basis":"pattern"},
-      "title": "Explicit targetType for Android createPost calls must not be hardcoded to COMMUNITY",
+      "title": "Android createPost targetType must be a valid, bound write target",
       "severity": "warning",
-      "rationale": "Android feed targets must be passed dynamically (e.g. from Intent extras or ViewModel state), not hardcoded as AmityPostTargetType.COMMUNITY.",
+      "rationale": "Android createPost targets must resolve to a valid SDK write target (user or community) with a targetId from Intent extras/ViewModel/auth/route state, never a global aggregate feed target.",
       "applies_when": {
         "platforms": [
           "android"
@@ -1647,7 +1669,7 @@
           "evidence_required": [
             {
               "field": "target_type_rationale",
-              "description": "Reason why this composer is hardcoded to a specific target type.",
+              "description": "Reason why this composer uses this targetType/targetId binding.",
               "upload_policy": "upload-with-consent"
             }
           ]
@@ -1658,9 +1680,9 @@
       "id": "flutter.feed.target-type-explicit",
       "version": 1,
       "symbol_anchored": {"platform":"flutter","types":["AmityPostTargetType"],"basis":"names-only"},
-      "title": "Explicit targetType for Flutter createPost calls must not be hardcoded to COMMUNITY",
+      "title": "Flutter createPost targetType must be a valid, bound write target",
       "severity": "warning",
-      "rationale": "Flutter feed targets must be passed dynamically (e.g. from Widget properties), not hardcoded as AmityPostTargetType.COMMUNITY.",
+      "rationale": "Flutter createPost targets must resolve to a valid SDK write target (user or community) with a targetId from Widget/auth/route state, never a global aggregate feed target.",
       "applies_when": {
         "platforms": [
           "flutter"
@@ -1684,7 +1706,7 @@
           "evidence_required": [
             {
               "field": "target_type_rationale",
-              "description": "Reason why this composer is hardcoded to a specific target type.",
+              "description": "Reason why this composer uses this targetType/targetId binding.",
               "upload_policy": "upload-with-consent"
             }
           ]
@@ -1695,9 +1717,9 @@
       "id": "ios.feed.target-type-explicit",
       "version": 1,
       "symbol_anchored": {"platform":"ios","types":["AmityPostTargetType"],"basis":"names-only"},
-      "title": "Explicit targetType for iOS createPost calls must not be hardcoded to COMMUNITY",
+      "title": "iOS createPost targetType must be a valid, bound write target",
       "severity": "warning",
-      "rationale": "iOS feed targets must be passed dynamically (e.g. from View state or initializer), not hardcoded as AmityPostTargetType.community.",
+      "rationale": "iOS createPost targets must resolve to a valid SDK write target (user or community) with a targetId from view/auth/route state, never a global aggregate feed target.",
       "applies_when": {
         "platforms": [
           "ios"
@@ -1721,7 +1743,7 @@
           "evidence_required": [
             {
               "field": "target_type_rationale",
-              "description": "Reason why this composer is hardcoded to a specific target type.",
+              "description": "Reason why this composer uses this targetType/targetId binding.",
               "upload_policy": "upload-with-consent"
             }
           ]

package/rules/live-data.yaml

@@ -524,7 +524,8 @@
           "human_allowed": false,
           "evidence_required": []
         }
-      }
+      },
+      "symptoms": ["notLoggedIn", "NOT_LOGGED_IN", "session is not established", "session not ready", "user is not logged in", "SessionState"]
     },
     {
       "id": "flutter.live-collection.session-ready-requery",
@@ -546,7 +547,8 @@
           "human_allowed": false,
           "evidence_required": []
         }
-      }
+      },
+      "symptoms": ["notLoggedIn", "NOT_LOGGED_IN", "session is not established", "session not ready", "user is not logged in", "SessionState"]
     },
     {
       "id": "ios.live-collection.session-ready-requery",
@@ -568,7 +570,8 @@
           "human_allowed": false,
           "evidence_required": []
         }
-      }
+      },
+      "symptoms": ["notLoggedIn", "NOT_LOGGED_IN", "session is not established", "session not ready", "user is not logged in", "SessionState"]
     },
     {
       "id": "typescript.live-collection.session-ready-requery",
@@ -590,7 +593,8 @@
           "human_allowed": false,
           "evidence_required": []
         }
-      }
+      },
+      "symptoms": ["notLoggedIn", "NOT_LOGGED_IN", "session is not established", "session not ready", "user is not logged in", "SessionState"]
     },
     {
       "id": "react-native.live-collection.session-ready-requery",
@@ -612,7 +616,8 @@
           "human_allowed": false,
           "evidence_required": []
         }
-      }
+      },
+      "symptoms": ["notLoggedIn", "NOT_LOGGED_IN", "session is not established", "session not ready", "user is not logged in", "SessionState"]
     }
   ]
 }

package/rules/sdk-lifecycle.yaml

@@ -2323,6 +2323,29 @@
       },
       "symptoms": ["Dependency-only integration", "Static social shell", "No SDK-backed runtime data"]
     },
+    {
+      "id": "ios.sdk.source-used",
+      "version": 1,
+      "title": "iOS SDK dependency must be used by product source",
+      "severity": "warning",
+      "rationale": "Installing the iOS social.plus SDK is not an integration. Product Swift source must use the SDK or UIKit manager beyond static initialization: login/register a runtime user and query or create social.plus data.",
+      "applies_when": {
+        "platforms": ["ios"],
+        "outcomes": ["setup-sdk", "setup-live-data", "add-feed", "add-comments", "add-chat", "add-community", "add-follow", "validate-setup"]
+      },
+      "enforcement": {
+        "deterministic": [
+          { "check": "validator-finding-absent", "finding_rule_id": "ios.sdk.source-used" }
+        ],
+        "attestation": {
+          "allowed": false,
+          "host_agent_min_confidence": "high",
+          "human_allowed": false,
+          "evidence_required": []
+        }
+      },
+      "symptoms": ["Dependency-only integration", "Static social shell", "No SDK-backed runtime data"]
+    },
     {
       "id": "react-native.ui.runtime-probe-copy",
       "version": 1,

package/skills/social-plus-vise/SKILL.md

@@ -19,9 +19,11 @@ vise plan . --request "<user intent>"
 vise init . --request "<user intent>"
 ```
 
+**This 3-step order is the single-surface path.** For a **broad / multi-surface / experience** request, `vise init` will *refuse* until the blueprint is signed off (exit 7) — so the real order there is `inspect → plan → creative → creative accept → workplan next` (sign the blueprint) `→ init` per surface. Do not treat the exit-7 refusal from `vise init` as an error: it means "run the workplan/blueprint gate first." The full multi-surface sequence is under "Blueprint sign-off" below; if you are unsure which path you are on, run `vise plan` and check for a `socialWorkplan` (multi-surface) or an `experienceHint` (a single-outcome request that likely wants expansion — run `vise creative`).
+
 For a **feed / community / experience** request, also run `vise creative . --request "<user intent>"` (the advisory Engagement Intelligence layer) before building — it surfaces engagement options (post types, polls, reactions, discovery/achievement loops) that `vise plan` only lists tersely under `optionalCapabilities` / `engagement`. Advisory, never a gate — full guidance under "Creative pre-planning" below.
 
-**You own the goal→experience inference; EI is advisory data, not a decider.** `vise plan`'s automatic `socialWorkplan` expansion is a deterministic *convenience* that fires only on explicit experience **vocabulary** ("community feed", "direct messaging", "discussion forum", "creator platform") — it will **not** expand a goal phrased in natural product language ("let runners form local clubs and share their weekend routes", "buyers and sellers negotiate a sale privately", "users ask questions and get threaded answers"). So when the goal is experience-shaped but `vise plan` returns **no** `socialWorkplan`, do not conclude there is no fuller experience: run `vise creative . --request "<goal>"`, read its `candidateSolutions` as the advisory **menu** of experiences, and **infer which one fits the user's intent yourself** — mapping a fuzzy goal to an experience is your job (you are the inferential layer), not a keyword match (`creative`'s ranking is advisory; the *right* candidate is often in the set but not ranked first).
+**You own the goal→experience inference; EI is advisory data, not a decider.** Multi-surface `socialWorkplan` expansion is driven by an accepted EI selection, not raw request keyword matching. If the goal is experience-shaped, run `vise creative . --request "<goal>"`, read its `candidateSolutions` as the advisory **menu** of experiences, and **infer which one fits the user's intent yourself** — mapping a fuzzy goal to an experience is your job (you are the inferential layer), not a keyword match (`creative`'s ranking is advisory; the *right* candidate is often in the set but not ranked first). Then accept the chosen variant so `vise workplan` and the blueprint gate have a concrete companion-surface sequence to govern. Never treat `vise plan` returning no `socialWorkplan` before `creative accept` as proof that no fuller experience applies.
 
 Before accepting a variant, **show the EI choice explicitly**. Do not compress this step into one sentence like "community-first is best." Present a compact decision block with:
 - recommended experience and 2-3 concrete request/project signals that make it fit;
@@ -77,7 +79,7 @@ renders feed, composer, comments, reactions, profile/follow, moderation, or chat
 - If data is absent, ask whether to prepare it in Console or create safe seed data through SDK functions before judging the integration. If they decline, say that only static checks / resolved empty states can be claimed, not populated product proof.
 - When safe SDK seed data is created, keep the returned community/feed/post/comment objects in runtime state or wait for a confirmed re-query/live-collection update before final handoff. A default path that still shows `0 posts`, `syncing`, `waiting on content`, create/prepare failure copy, or only disabled affordances is not populated runtime proof. If the exact product-context target cannot be created or populated because of tenant permissions or review mode, fall back to the nearest discovered readable target with visible posts/messages/users and map it back into the product context with honest copy. Do not silently swallow seed/query errors; record failures in handoff notes and show a product-native retry/error state.
 - Do not dump arbitrary readable tenant data into product UI just because discovery returned it. Filter discovered communities/users/channels by product context, or create a product-native seed target. Names/descriptions that are raw IDs, numeric-only labels, short random strings such as `rand2`, lorem/test data, `sampleapp` fixtures, or unrelated generated business copy are not natural targets; hide or skip them and keep searching/seeding before claiming runtime proof. Prefer a product-owned namespace/allowlist such as app-created names, metadata tags, session/program identifiers, or cached IDs returned by the app's own create flow; if the SDK query returns mixed tenant data, render only product-safe matches and never let an unsafe target become the active selected context. Deduplicate discovered/seeded targets by stable SDK ID or normalized product label, and prioritize populated product-owned targets before empty clones; a long rail of repeated zero-post targets is not polished populated proof. Do not rewrite unsafe tenant labels into product copy to make them look acceptable — exclude the object. Apply this filtering to every visible rail/list/card and author fallback, not only the selected target.
-- Runtime proof can consume browser/simulator/emulator/device resources and additional agent tokens. Ask the user before running it; if they decline, explain the remaining runtime risks instead of claiming the app was proven at runtime.
+- Runtime proof can consume browser/simulator/emulator/device resources and additional agent tokens. Ask the user before running it; if they decline, explain the remaining runtime risks instead of claiming the app was proven at runtime. **Precedence (resolves the apparent conflict with "Pre-authorized dogfood/benchmark sign-off" above):** the "ask first" rule is the default for an interactive session. A dogfood/benchmark prompt that *explicitly* grants runtime-proof consent (per that clause) IS the user's answer — do not re-ask in that run. If consent was neither given interactively nor explicitly in the prompt, do not run device/browser proof: proceed with static checks and say so. Never infer consent from silence.
 - Record the expected smoke level: use `populated` for data-backed surfaces where empty screens are not product proof, and `resolved` only where an empty state is legitimate.
 - Never delete a runnable entry file such as `App.tsx`, `lib/main.dart`, or the app's root view as a standalone step while preparing a replacement. Edit it in place, or add/import a new child component/widget first, so interruptions and failed patches do not leave the project without an entry point.
 - Record runtime readiness/proof status in evidence files, screenshots, or handoff notes — not as end-user product UI. Do not ship visible `CLIENT`, `SESSION`, `RUNTIME`, SDK, env-var, region, setup, readiness-debug labels, runtime/probe/status panels, or hidden no-op controls just to prove the app connected; the normal screen should express the product state naturally.
@@ -85,7 +87,7 @@ renders feed, composer, comments, reactions, profile/follow, moderation, or chat
 - A repository query that stores SDK objects in state but never renders or passes that state into a visible widget/component is a hidden no-op, not runtime proof. The first social surface must consume SDK-returned communities/posts/comments/users in the actual product tree; returning the original screen after setup/login is still a failed integration.
 - Native runtime proof must make the core social loop visibly reachable. Do not spend the whole first viewport on intro, hero, or community chrome while feed/composer/comment/reaction/report/profile surfaces are buried below an unverified scroll. For Flutter and React Native dogfood, keep at least one SDK-backed feed item and key actions visible in the initial route, or expose them through obvious product tabs/buttons that screenshots can capture; automated text/tap probes may not see Flutter/RN accessibility text.
 - Runtime screenshots must be product-clean. Flutter/React Native debug artifacts such as yellow/black `RenderFlex` overflow banners, `BOTTOM OVERFLOWED BY ... PIXELS`, red error boxes, or clipped action rows are runtime failures to repair, not acceptable evidence. Use bounded card dimensions, `Flexible`/`Expanded`/`Wrap`, `maxLines`, ellipsis, and responsive spacing before handoff.
-- If `vise check` fails `<platform>.live-collection.session-ready-requery` because `sp-vise/evidence/runtime-smoke.json` is missing or failed, do **not** attest it and do not call the surface complete. Declare `sp-vise/smoke.json` for the mounted collection surfaces, emit log-only markers from the real SDK query lifecycle (`VISE_SMOKE surface=<id> state=loading|empty|loaded count=N|error:<message>`), cold-launch the app into the social route, capture the device/browser log, run `vise smoke . --log <capture>`, and rerun `vise check . --ci`. The markers must never include secrets, PII, raw social IDs, or end-user setup/debug labels; they are evidence artifacts, not product UI. For Flutter/React Native dogfood, capture bounded Android logcat/simulator logs before `workplan complete` when the surface uses live collections.
+**Recovering a red `<platform>.live-collection.session-ready-requery` (this is a GATE remedy — NOT advisory like the bullets above; the surface cannot go green or be completed without it).** If `vise check` fails `<platform>.live-collection.session-ready-requery` because `sp-vise/evidence/runtime-smoke.json` is missing or failed, do **not** attest it and do not call the surface complete. Declare `sp-vise/smoke.json` for the mounted collection surfaces, emit log-only markers from the real SDK query lifecycle (`VISE_SMOKE surface=<id> state=loading|empty|loaded count=N|error:<message>`), cold-launch the app into the social route, capture the device/browser log, run `vise smoke . --log <capture>`, and rerun `vise check . --ci`. The markers must never include secrets, PII, raw social IDs, or end-user setup/debug labels; they are evidence artifacts, not product UI. For Flutter/React Native dogfood, capture bounded Android logcat/simulator logs before `workplan complete` when the surface uses live collections. (See also `vise debug` — the requery rules now carry session-state symptoms, so a pasted `notLoggedIn`/`session not established` crash correlates here.)
 
 Implement one surface at a time. Surface that focused plan's intake questions to
 the user, including opt-in capability questions, then run the normal check loop.
@@ -104,9 +106,10 @@ vise workplan status . --request "<user intent>"
 
 `workplan complete` is evidence-backed: it refuses non-green `vise check`
 results and snapshots the surface's compliance/check sidecar under
-`sp-vise/workplan-snapshots/<surface>/`. Repeat until `workplan status` reports
-the broad request complete, then run one final `vise check`, `vise validate`,
-and `vise run-sensors` before handoff.
+`sp-vise/workplan-snapshots/<surface>/` with a snapshot integrity manifest.
+`workplan status` ignores missing or drifted snapshot evidence. Repeat until it
+reports the broad request complete, then run one final `vise check`,
+`vise validate`, and `vise run-sensors` before handoff.
 
 Then fetch docs cited by the plan or relevant to the requested feature:
 
@@ -115,7 +118,7 @@ vise search-docs "<SDK feature or API pattern>"
 vise get-doc-page "<canonical-doc-path>"
 ```
 
-**Implementation pacing matters.** Once the blueprint/intake gates are clear, make a visible product-source edit before broad research: route the host entry point to the new social surface, or create and import a product-native component for that surface. In bounded dogfood/benchmark runs, this is a hard ordering requirement: after the first `vise init` or focused surface command clears, edit product source before fetching a second docs page, grepping generated SDK/framework interfaces, resolving broad native package internals, or polishing UI. Do not create a shell-first component; the first social component should already import the relevant social.plus SDK package and contain setup/login plus at least one SDK data API call. If you need exact symbols, use package-root imports first, inspect the narrow package-root exports or one targeted type file, then let TypeScript/build errors guide the next lookup. Do not stop at static feature-preview cards that merely describe feed/comments/reactions/profile/chat; those are product copy, not integration. A run that only creates `sp-vise/` artifacts, installs dependencies, reads docs, edits dependency manifests/project files, or stops at a product-looking shell without SDK-backed source is not a completed Vise implementation.
+**Implementation pacing matters.** Once the blueprint/intake gates are clear, make a visible product-source edit before broad research: route the host entry point to the new social surface, or create and import a product-native component for that surface. In bounded dogfood/benchmark runs, this is a hard ordering requirement: after the first `vise init` or focused surface command clears, edit product source before fetching a second docs page, grepping generated SDK/framework interfaces, resolving broad native package internals, or polishing UI. (No contradiction with the Required Loop / per-feature `vise search-docs` recipes: the *first* docs fetch that the plan or feature recipe calls for is expected — this rule only bars *stacking more* research before your first SDK-backed edit. Fetch once, edit, then let build/type errors drive further lookups.) Do not create a shell-first component; the first social component should already import the relevant social.plus SDK package and contain setup/login plus at least one SDK data API call. If you need exact symbols, use package-root imports first, inspect the narrow package-root exports or one targeted type file, then let TypeScript/build errors guide the next lookup. Do not stop at static feature-preview cards that merely describe feed/comments/reactions/profile/chat; those are product copy, not integration. A run that only creates `sp-vise/` artifacts, installs dependencies, reads docs, edits dependency manifests/project files, or stops at a product-looking shell without SDK-backed source is not a completed Vise implementation.
 
 The visible edit must also **use** the SDK data it fetches. If you add `_communities`, `posts`, `comments`, or similar SDK-backed state, render it or pass it into a rendered child before moving on. Unused SDK state, hidden controls, `void Repository` markers, iOS `let _ = AmityCommunityRepository.self` / type-only repository references, or a wrapper that still returns the original product screen are scanner-only integration and should be fixed before `vise check`.
 
@@ -166,6 +169,17 @@ Treat Vise runtime smoke sensors as real validation. For TypeScript/React Native
 
 In CI or pull-request pipelines, use `vise check . --ci`. It is read-only, exits non-zero unless compliance is green, and never writes deterministic-pass records; use `vise sync` only during the implementation loop after a local green check.
 
+## Resuming an in-progress flow
+
+The `sp-vise/` sidecar IS the flow's state — Vise re-derives from it on every command, so a flow is resumable across turns and never restarts from scratch. When the user says "continue" (or you pick up a partially-built integration):
+
+- **Run `vise workplan status . --request "<intent>"` FIRST.** It reads the sidecar directly and tells you exactly where the journey stands — completed surfaces, the next pending surface, the accepted experience, and the signed blueprint — so you don't re-plan or re-ask decisions Vise already recorded (an accepted `vise creative` variant, the signed `blueprint_confirmation`, the chosen `solution_path`, and completed surfaces all persist and are replayed).
+- **Prefer the ORIGINAL request wording.** Resume matching is deterministic (not semantic): the same/substring request, or one whose resolved outcome is a stage of the signed journey (or a companion — comments↔feed), re-attaches. A loosely reworded request may not; when in doubt, reuse the exact original request string.
+- **`status: "not-applicable"` does not mean "nothing to do."** If a signed multi-surface flow exists but your request didn't re-attach, the response carries a `signedFlowAvailable` block naming the canonical request and how to resume. Re-run with that request rather than starting a fresh single-surface build that would orphan the journey.
+- **Do not hand-edit the sidecar to "fix" state.** `flow.json`, `workplan.json`, and the snapshot manifests are integrity-checked; a hand-authored progress/snapshot entry is ignored. Drive state only through the `vise` commands.
+
+**When runtime proof can't be produced (declined / deviceless CI).** If the user declines device/emulator runtime proof, or you're in a deviceless environment, do not leave a live-collection surface stuck red-forever and do not fake evidence. Record an honest, auditable waiver: `vise smoke waive . --reason "<why proof isn't being run>" --mode declined|deviceless`. `vise check` then reports `runtime-proof-waived` (exit 9 — CI still blocks by default; pass `--allow-proof-waiver` to accept it and exit 0), and `vise workplan complete` will record the surface with the waiver noted. A waiver is an explicit UNDER-claim — never report a waived surface as "runtime-proven"; state in the handoff that only static checks are claimed. Remove `sp-vise/evidence/runtime-proof-waiver.json` once real proof is captured; genuine passing runtime-smoke evidence always overrides a waiver.
+
 ## Prefer Installable Blocks When a Registry Is Available (preview)
 
 **Installable social.plus blocks are a preview capability that requires a block registry.** A registry is not generally available yet, so unless the user explicitly provides a `--registry <path>` or `sp-vise/blocks.json` already exists in the project, hand-build the surface as normal — the rest of this skill fully governs the hand-built path. When a registry IS provided, run `vise blocks list --registry <path>` before implementing the surface by hand. When a block exists for the outcome, prefer the governed install path:
@@ -182,7 +196,7 @@ No registry available means hand-build as normal — never assume a block or a r
 
 ## Debugging (Day 2 Operations)
 
-If the customer reports an **SDK-specific** runtime crash, build failure, or data-not-loading bug, start with `vise debug .` (with `--error` / `--error-file`) **before** broad repo inspection — do not guess the fix first. Scope limit: only for errors mentioning `social.plus`/`Amity`/`live-collection` or in files importing the SDK; never for generic UI/CSS issues. Full `vise debug` workflow and `repairBrief` format: **see `reference/debugging.md`**.
+If the customer reports an **SDK-specific** runtime crash, build failure, or data-not-loading bug, start with `vise debug .` (with `--error` / `--error-file`) **before** broad repo inspection — do not guess the fix first. Scope limit: only for errors mentioning `social.plus`/`Amity`/`live-collection`, **or whose stack/blame points at a file that imports the SDK, or that surfaced on an SDK-backed social surface** (feed/comments/chat/community/profile). The error *text* need not contain those keywords — a generic-looking `NullPointerException`, `401`, `OutOfMemoryError`, or a `notLoggedIn`/`session not established` message thrown from the social path IS in scope (that is exactly the flagship "feed stays empty / signing-in" class). Skip only genuinely non-SDK UI/CSS/build issues unrelated to any social surface. Full `vise debug` workflow and `repairBrief` format: **see `reference/debugging.md`**.
 
 (If `vise` isn't installed: `npm install -g @amityco/social-plus-vise`. Engagement-scope handling — `sp-vise/engagement.json` — is in `reference/operations.md`.)
 
@@ -290,7 +304,7 @@ A read *count* with no way to clear it is half a feature: when a channel/thread
 
 A sent message starts in a `syncing` state and can land in `error` (e.g. network failure, or after an SDK session restart). A composer that renders only the optimistic success leaves failed messages silently stuck.
 
-- **Correct pattern**: Observe each message's `syncState` and surface failed sends with a retry/delete affordance; clean up unrecoverable failures (e.g. `deleteFailedMessages()`) on init.
+- **Correct pattern**: Observe each message's `syncState` and surface failed sends with a retry/delete affordance; where the platform SDK exposes a failed-message cleanup helper, use it on init, otherwise keep retry/delete behavior in product state with supported message APIs.
 - **Wrong pattern**: Calling `createMessage` and rendering success unconditionally, with no handling for the `error` syncState.
 
 ### File Upload & Media
@@ -316,6 +330,12 @@ When querying lists of entities (e.g., `getPosts`, `getCommunityFeed`), always u
 
 When using a LiveCollection or live object, also handle connection-state changes. The SDK exposes a connection state stream; render a "reconnecting" indicator or disable interaction controls when the connection is lost. An app that silently shows stale data on network drops generates support tickets attributed to the SDK rather than the integration.
 
+### Seeding Data When Empty (read-after-write lag)
+When a surface has no product data and you create safe seed data through the SDK (`createCommunity` / `createChannel` / `createPost`), a **freshly created object does not reliably reappear in an immediate list re-query** — the backing list index lags the write, often returning empty across several cold-launch attempts. Treating the empty re-query as "no data" is the single biggest time-sink when populating a first surface (observed repeatedly on native dogfoods where a community was created but the crew list re-query stayed empty).
+- **Correct pattern:** Merge the create-response object **directly into the rendered/published list** (keyed by its returned ID) instead of waiting for the list re-query to catch up. **Persist created IDs** to local storage/cache (`UserDefaults`/`localStorage`/prefs — never a source constant) so a relaunch rehydrates via a **direct `getCommunity(id)` / `getChannel(id)` fetch** (immune to list-index lag) rather than re-seeding duplicates.
+- **Wrong pattern:** `create(...)` → immediately re-query the list → render the (still-empty) list → conclude "seeding failed / no data". Also wrong: re-seeding on every launch because the previous run's IDs weren't persisted, producing a rail of duplicate crews.
+- **Bounded retry, not give-up or infinite-spin:** a cold launch can transiently return `401`/`notLoggedIn` or a stalled first query before the session settles (see Session Renewal). Wrap seeding + the first query in a **bounded** retry (a few attempts with backoff) that ends in a product-native retry affordance — never an unbounded loop and never a silent swallow. Do not fire the seed/query in the same synchronous tick as `login()`.
+
 ### Post Status Filters
 Always filter post queries to exclude deleted or flagged content. Amity's older SDKs include flagged/deleted posts by default, which can leak moderated content into the feed UI if unfiltered.
 - **Correct pattern:** Apply `.includeDeleted(false)`, `.statuses([.published])`, or `.feedType(AmityFeedType.PUBLISHED)` to your query builders.
@@ -354,8 +374,8 @@ A comment thread is incomplete if it only lists comments. Users expect to post.
 
 ### Explicit Feed Target Types
 When calling `createPost`, do not hardcode the `targetType` to a literal value like `AmityPostTargetType.COMMUNITY` if the composer component is meant to be reusable.
-- **Correct pattern:** Pass the `targetType` dynamically (e.g. from props, parameters, or intent extras) so the composer can post to a user feed, community feed, or global feed interchangeably.
-- **Wrong pattern:** Hardcoding `targetType: AmityPostTargetType.COMMUNITY` inside a generic post composer.
+- **Correct pattern:** Pass the `targetType` dynamically (e.g. from props, parameters, or intent extras) so the composer can post to a valid SDK target: user or community. A global feed is an aggregate read surface from followed users and joined communities; it is not a post creation target.
+- **Wrong pattern:** Hardcoding `targetType: AmityPostTargetType.COMMUNITY` inside a generic post composer, or offering `global` as a createPost target.
 
 ### Comment Reference Type Enum
 When creating comments, always use the SDK's provided enum types for the reference type rather than raw string literals.
@@ -406,7 +426,7 @@ On **iOS**, the SwiftPM package is `github.com/AmityCo/Amity-Social-Cloud-SDK-iO
 
 ## Resolving `vise check` Findings
 
-`vise check` reports each rule as `deterministic-pass`, `attestation-needed`, `failed`, or `blocked`. **`attestation-needed` and `failed` block "I'm done" — they are not skippable warnings.** Resolve each one of two ways: (1) **preferred** — adjust the code so the deterministic check fires (`vise explain <rule-id>` shows what it wants), then `vise check` green → `vise sync`; or (2) record `vise attest` with evidence when the architecture is genuinely unconventional. Confidence honesty, the `vise attest` evidence-file format, escalation/human-signer rules, and "`vise sync` is not attestation": **see `reference/operations.md`**.
+`vise check` reports overall statuses such as `green`, `needs-attestation`, `deterministic-failures`, `blocked`, `contract-drift`, `completeness-gap`, `selected-capability-failures`, `no-platform` (no social.plus SDK platform detected — reported as a failure, never a vacuous green), and `runtime-proof-waived` (see the runtime-proof waiver note above); individual rules use `deterministic-pass`, `deterministic-fail`, `attestation-needed`, `blocked`, `stale`, or `advisory`. **Non-green statuses block "I'm done" — they are not skippable warnings.** Resolve each one of two ways: (1) **preferred** — adjust the code so the deterministic check fires (`vise explain <rule-id>` shows what it wants), then `vise check` green → `vise sync`; or (2) record `vise attest` with evidence when the architecture is genuinely unconventional and the rule allows attestation. Confidence honesty, the `vise attest` evidence-file format, escalation/human-signer rules, and "`vise sync` is not attestation": **see `reference/operations.md`**.
 
 ## Feature Guidance
 
@@ -520,7 +540,7 @@ vise search-docs "community create join leave members invitation"
 vise plan . --request "<community request>"
 ```
 
-Require the community surface (create, browse/join, detail + members, or membership management), the privacy model (public instant-join vs private join-request approval — they differ), and a natural community source (discovery query, create-flow return value, route/app state, or user selection; never hardcode a communityId). Query communities and members through a Live Collection, handle the join-request flow for private communities, gate moderator actions (roles/ban) by role, and clean up observers. `vise plan` returns the community `completenessChecklist`; opt out of anything out of scope with `// vise: scope-omit <id> <reason>`.
+Require the community surface (create, browse/join, detail + members, or membership management), the privacy model (public instant-join vs private join-request approval — they differ), and a natural community source (discovery query, create-flow return value, route/app state, or user selection; never hardcode a communityId). Query communities and members through a Live Collection, handle the join-request flow for private communities, gate moderator actions (roles/ban) by role, and clean up observers. `vise plan` returns the community `completenessChecklist`; opt out of anything out of scope with `// vise: scope-omit <id> — <reason>`.
 
 For the social graph (follow/followers):