@amityco/social-plus-vise 1.4.3 → 1.4.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/CHANGELOG.md +6 -0
  2. package/README.md +26 -31
  3. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -8,6 +8,12 @@ The format is loosely based on [Keep a Changelog](https://keepachangelog.com/en/
8
8
 
9
9
  No changes yet.
10
10
 
11
+ ## 1.4.4 — 2026-07-02
12
+
13
+ ### Changed
14
+ - **Public npm README tightened.** The evidence section now reads as a concise customer-facing scorecard, removes internal benchmark caveats and launch-verification lab notes, and avoids links to benchmark files that are not shipped in the npm package.
15
+ - **Validation-layer coverage clarified.** The README now states directly that the current package covers all three validation layers: SDK compliance, feature completeness, and advisory design conformance.
16
+
11
17
  ## 1.4.3 — 2026-07-02
12
18
 
13
19
  ### Changed
package/README.md CHANGED
@@ -38,7 +38,7 @@
38
38
  While the agent works, Vise:
39
39
 
40
40
  - 🧠 **Grounds it in the real SDK** — extracted, source-anchored facts (real types and field names), so it won't invent a symbol or field the SDK doesn't expose, and pins the version published on npm.
41
- - 🛡️ **Enforces 300+ platform-specific compliance rules** — the mistakes that pass a demo and break in production.
41
+ - 🛡️ **Enforces 400+ platform-specific checks** — the mistakes that pass a demo and break in production.
42
42
  - ✅ **Gates feature completeness** — the whole outcome (pagination, empty/error states, the capabilities you asked for), not just the happy path.
43
43
  - 🎨 **Checks generated UI against your design system.**
44
44
  - 🔧 **Runs your project's own build / lint / typecheck sensors.**
@@ -77,7 +77,7 @@ vise install-skill --target copilot . # GitHub Copilot / VS Code
77
77
  # "Add a social feed to this app using the social.plus SDK."
78
78
  ```
79
79
 
80
- The skill drives the loop automatically — `vise inspect` → `vise plan` → `vise init` → edit code → `vise check` → `vise run-sensors`. You drive intent, answer scope questions, and **sign off the blueprint** (what gets built) before the agent writes a line; Vise keeps the agent honest. For dogfood or release proof, also launch the app and capture runtime evidence; static checks do not replace seeing the surface run. See [How it works](#how-it-works).
80
+ The skill drives the loop automatically — `vise inspect` → `vise plan` → `vise init` → edit code → `vise check` → `vise run-sensors`. You drive intent, answer scope questions, and **sign off the blueprint** (what gets built) before the agent writes a line; Vise keeps the agent honest. For high-confidence handoff, also launch the app in its real browser, simulator, emulator, or device target and verify the selected social surface with real data. See [How it works](#how-it-works).
81
81
 
82
82
  All skill targets:
83
83
 
@@ -103,7 +103,7 @@ Prefer a per-project install? `npm install -D @amityco/social-plus-vise`, then c
103
103
  4. **Build** — the agent edits your code, grounded by `vise search-docs` and `vise get-doc-page`.
104
104
  5. **Check & repair** — `vise check` reports deterministic findings, completeness gaps, and attestation needs. The agent fixes findings or records attestations with evidence, looping until green.
105
105
  6. **Sense** — `vise run-sensors` runs your project's own typecheck/build/lint/SDK smokes. Done means the contract and evidence are committed, not just that the agent stopped.
106
- 7. **Prove runtime readiness** — for dogfood, release, or any user-visible handoff, ask before spending browser/simulator/emulator/device resources. If approved, boot the actual target, capture screenshots/logs, and record what data was discovered or created at runtime. Discover targets naturally from host app state, SDK queries, user selection, or SDK create-flow return values; if the tenant has no data, ask whether to prepare Console data or seed safe dogfood data before claiming populated proof. When a `sp-vise/smoke.json` contract exists, run `vise smoke` against captured logs; `expect: "populated"` requires `loaded count=N` with `N > 0`. If runtime proof is declined or a completed native output cannot be archived, say so explicitly; starter launch proof is useful, but it is not proof that the completed social.plus surface ran.
106
+ 7. **Launch and verify** — for any user-visible handoff, ask before spending browser/simulator/emulator/device resources. If approved, open the actual target, check the selected journey, and record what data was discovered or created. Discover targets naturally from host app state, SDK queries, user selection, or SDK create-flow return values; if the tenant has no data, prepare Console data or seed safe sample data before calling the surface populated. When a `sp-vise/smoke.json` contract exists, run `vise smoke` against captured logs; `expect: "populated"` requires `loaded count=N` with `N > 0`. If launch verification is skipped, say what remains unverified.
107
107
 
108
108
  ### Solution path & UIKit routing (advisory)
109
109
 
@@ -113,23 +113,23 @@ When UIKit is in play, `vise plan` can also emit **`uikitCustomization`**, recom
113
113
 
114
114
  ### Three validation layers
115
115
 
116
- The layer is set by the *kind of claim*, which is how Vise is designed to avoid false positives where it gates:
116
+ The layer is set by the *kind of claim*, which is how Vise avoids treating "looks plausible" as "ready to ship." The current package covers all three layers across supported platforms: compliance and completeness are enforced by `vise check`, while design conformance is available as an advisory review loop.
117
117
 
118
118
  | Layer | Claim | How | Enforcement |
119
119
  |---|---|---|---|
120
- | **SDK compliance** | "this is **wrong**" | 300+ deterministic rules (session renewal, live-collection vs one-shot, secret hygiene, parent-child rendering, ban-state gating…) | **Hard gate** — `vise check` blocks until green or attested; a small advisory subset never blocks |
120
+ | **SDK compliance** | "this is **wrong**" | 400+ deterministic checks (session renewal, live-collection vs one-shot, secret hygiene, parent-child rendering, ban-state gating…) | **Hard gate** — `vise check` blocks until green or attested; a small advisory subset never blocks |
121
121
  | **Feature completeness** | "this is **missing**" | A narrow mandatory baseline per outcome (pagination for feeds, a composer for comments, send + read state for chat, SDK-backed counts for profiles); richer capabilities are explicit opt-ins from `vise plan` | **Decision gate** — `vise check` exits `completeness-gap` until each baseline item is built or opted out with `// vise: scope-omit <id> — <reason>` |
122
122
  | **Design conformance** | "this **looks off**" | Extract your design system into a contract, confirm a preview, then check token usage | **Advisory** — `vise design check`/`preview`; never fails a build |
123
123
 
124
- Correctness is gated by deterministic rules or attestations; completeness is gated by explicit scope decisions; conformance stays advisory because "matches the brand" is legitimately subjective. Each gating rule is itself mutation-verified — its fix is reverted to confirm the check actually fails without it, so a rule that can't fail is removed rather than shipped as theater. `vise explain <ruleId>` prints any rule's rationale, evidence requirements, and remediation.
124
+ Correctness is gated by deterministic rules or attestations; completeness is gated by explicit scope decisions; conformance stays advisory because "matches the brand" is legitimately subjective. `vise explain <ruleId>` prints any rule's rationale, evidence requirements, and remediation.
125
125
 
126
- Runtime proof is a separate evidence layer. `vise check` and `vise run-sensors` can prove structure, completeness, and local build commands, but they cannot prove that the selected community/feed/chat route renders on a cold launch. Ask before running browser or native runtime proof because it can consume local resources and agent tokens. If the user declines, state the expected limitation: cold-launch session races, empty tenant data, route wiring, permissions, and native packaging remain unproven. Use `vise smoke` where the app declares a runtime-smoke contract.
126
+ App launch verification is the final acceptance step outside these three layers. `vise check` and `vise run-sensors` can prove structure, completeness, and local build commands; a browser or native launch confirms the selected user journey is actually visible.
127
127
 
128
128
  **Supported outcomes:** feed · comments · chat · moderation · community · social graph (follow) · in-app notifications · plus setup (SDK, push, live data). `vise plan`/`init` classify the request and tailor the plan, rules, and feature checklist.
129
129
 
130
130
  ### Engagement Intelligence
131
131
 
132
- **Advisory, in preview.** The three layers above answer *whether you built it right*. Ahead of the build, Vise can also help reason about *what to build*: an **Engagement Intelligence** layer turns a product goal into multiple candidate **engagement strategies** — archetypes, UX patterns, and solution variants drawn from a social.plus experience catalog — with rationale, tradeoffs, no-fit guidance, availability boundaries, and review gaps. The driving agent presents the EI choice as a visible decision — recommended experience, concrete fit signals, credible alternatives, tradeoffs, expected blueprint surfaces, and no-fit option — before it accepts a variant. The human or driving agent still chooses the direction, then Vise compiles that selected variant into an implementation plan (`vise creative` → `vise creative accept` → `vise experience compile`), optionally bridging to installable social.plus blocks, plus advisory UX expectations and a multi-dimension experience review.
132
+ **Advisory, in preview.** The three layers above answer *whether you built it right*. Ahead of the build, Vise can also help reason about *what to build*: an **Engagement Intelligence** layer turns a product goal into multiple candidate **engagement strategies** — archetypes, UX patterns, and solution variants drawn from a social.plus experience catalog — with rationale, tradeoffs, no-fit guidance, availability limits, and review gaps. The driving agent presents the EI choice as a visible decision — recommended experience, concrete fit signals, credible alternatives, tradeoffs, expected blueprint surfaces, and no-fit option — before it accepts a variant. The human or driving agent still chooses the direction, then Vise compiles that selected variant into an implementation plan (`vise creative` → `vise creative accept` → `vise experience compile`), optionally bridging to installable social.plus blocks, plus advisory UX expectations and a multi-dimension experience review.
133
133
 
134
134
  It is **local-only, never uploads, carries no calibrated score**, and **never changes `vise check`'s exit codes**. The opt-in ranking preview is review context, not a top-1 confidence claim or autonomous product-strategy selector. Use it to shape the work; the validation layers still decide when it's done.
135
135
 
@@ -139,33 +139,28 @@ Vise can ingest your aesthetic from an HTML/CSS prototype (`vise design extract`
139
139
 
140
140
  ## Evidence
141
141
 
142
- Vise's measured effect is on whether an agent builds the *whole* outcome: runtime-visible social surfaces, natural target discovery, SDK setup/login, selected capabilities, design fit, correctness, and the app's own build/runtime proof. The durable finding is the **mechanism**: a checked verification loop changes the stopping condition. The agent is not done when the code compiles; it is done when the local contract is green, attested, runtime-proven, or explicitly blocked on a customer decision.
142
+ Vise is measured against complete brownfield integrations, not isolated snippets. In the real end-to-end benchmark suite, agents were asked to add social.plus to existing product-shaped apps across five platforms. The score combines workflow guidance, product surface completion, design fit, correctness, and efficiency.
143
143
 
144
- **Current real-E2E scorecard** — latest post-improvement Vise runs vs the strongest usable no-Vise controls captured for the same platform families:
144
+ **Current end-to-end scorecard**
145
145
 
146
- | Platform | Scenario | Vise overall | No-Vise control | Lift | Runtime proof |
147
- |---|---|---:|---:|---:|---:|
148
- | **Android** | market-pulse | **94.3** | 31.2 | **+63.1** | 9/9 |
149
- | **iOS** | luminary-club | **90.1** | 43.0 | **+47.1** | 9/9 |
150
- | **Web** | pulse-studio | **91.4** | 65.6 | **+25.8** | 8/9 |
151
- | **Flutter** | fieldhouse-club | **92.8** | 33.0 | **+59.8** | launched, 28 screenshots |
152
- | **React Native** | arena-fit | **90.3** | 67.3 | **+23.0** | launched, 16 screenshots |
146
+ | Platform | Scenario | With Vise | Without Vise | Improvement |
147
+ |---|---|---:|---:|---:|
148
+ | **Android** | market-pulse | **94.3** | 31.2 | **+63.1** |
149
+ | **iOS** | luminary-club | **90.1** | 43.0 | **+47.1** |
150
+ | **Web** | pulse-studio | **91.4** | 65.6 | **+25.8** |
151
+ | **Flutter** | fieldhouse-club | **92.8** | 33.0 | **+59.8** |
152
+ | **React Native** | arena-fit | **90.3** | 67.3 | **+23.0** |
153
153
 
154
- Average Vise score: **91.8**. Average no-Vise score: **48.0**. Average lift: **+43.8 points**.
154
+ Average with Vise: **91.8**. Average without Vise: **48.0**. Average improvement: **+43.8 points**.
155
155
 
156
- The scorecard is retained in [`benchmarks/real-e2e/RESULTS.md`](benchmarks/real-e2e/RESULTS.md), with weights and caps documented in [`benchmarks/real-e2e/SCORING_METHODOLOGY.md`](benchmarks/real-e2e/SCORING_METHODOLOGY.md). It measures capability activation, product outcome, design integration, correctness, efficiency, and runtime evidence. The remaining Web gap was chat runtime proof; community, feed, composer, comment preview, reactions, profile/follow, moderation, and SDK runtime proof were present in the Vise arms. The Flutter no-Vise control is a valid bad outcome: the agent deleted `lib/main.dart`, left the entry point missing, and the watchdog stopped the sample before runtime launch.
156
+ What changed with Vise in the loop:
157
157
 
158
- What changed in the winning Vise arms:
158
+ - The agent starts from a grounded plan instead of guessing the integration shape.
159
+ - Product targets are discovered naturally from app state, SDK queries, user choices, or SDK create-flow results, not hardcoded IDs.
160
+ - The stopping condition changes from "code was written" to "the requested social surface is planned, checked, and sensor-validated."
161
+ - The same workflow applies across web, React Native, Flutter, Android, and iOS.
159
162
 
160
- - Runtime readiness is treated as a gate before dogfood proof: identity, credentials, target discovery, tenant data, and proof consent must be resolved or explicitly deferred.
161
- - Agents are steered away from hardcoded `communityId`, `postId`, `channelId`, and `targetId` values; targets must come from host state, SDK queries, SDK create results, or safe fixture state.
162
- - Runtime errors block proof instead of being treated as cosmetic.
163
- - Native scoring recognizes real Android/iOS SDK setup and login patterns, not only surface-level type declarations.
164
- - Generated artifacts are filtered during secret checks so benchmark evidence does not pollute product scoring.
165
-
166
- **Boundaries:** these are social.plus's own measurements, not a third-party audit. The scorecard is a current-loop result, not a same-minute paired A/B rerun: the Vise column uses final post-improvement runs, while the no-Vise column uses the best available controls for the same platform families, including fresh React Native and Flutter controls from 2026-07-02. For a formal public benchmark, rerun both arms from clean fixtures under a frozen protocol and score them with the same scorer version. Older Flutter/React Native paired rows from 2026-06-29 are superseded because both were capped by incomplete runtime proof. Older README benchmark figures were removed because they came from earlier builds and older protocols.
167
-
168
- <sub>Cursor, Claude, Codex, GitHub Copilot, VS Code, and other product names are trademarks of their respective owners; social.plus is not affiliated with or endorsed by them. Benchmark figures are from social.plus's own measurements.</sub>
163
+ <sub>Cursor, Claude, Codex, GitHub Copilot, VS Code, and other product names are trademarks of their respective owners; social.plus is not affiliated with or endorsed by them.</sub>
169
164
 
170
165
  ## Supported Platforms
171
166
 
@@ -191,7 +186,7 @@ Run `vise <command> --help` for full flags. JSON output is the default for agent
191
186
  | `vise doctor` | Verify install; print version, install path, docs source |
192
187
  | `vise inspect [path]` | Detect platform, monorepo surfaces, design signals, available sensors |
193
188
  | `vise plan [path] --request "..." [--summary]` | Grounded implementation plan with intake questions and docs citations; `--summary` prints a compact route/intake view |
194
- | `vise plan --summary "..."` | Shortcut for quick routing dogfood or discovery when the current directory is the repo |
189
+ | `vise plan --summary "..."` | Shortcut for quick routing or discovery when the current directory is the repo |
195
190
  | `vise plan-harness [path] --request "..."` | Pre-planning step: build the harness around the request |
196
191
  | `vise init [path] --request "..." [--answer key=value]` | Write the `sp-vise/` compliance contract once blocking intake is answered; exits 7 (`needs-clarification`) otherwise |
197
192
  | `vise workplan next [path] --request "..."` | For broad social requests: print the next uncompleted surface and its focused commands |
@@ -253,7 +248,7 @@ Everything in this group is local and advisory: no uploads, no `vise check` exit
253
248
  | Command | Purpose |
254
249
  |---|---|
255
250
  | `vise run-sensors [path] [--dry-run]` | Run detected project scripts (npm, Gradle, Flutter, lint, typecheck, SDK smokes); `--dry-run` lists without executing |
256
- | `vise smoke [path] --log <file>` | Assess a captured runtime mount-smoke log into a pass/fail verdict + record evidence. `expect: "populated"` requires `loaded count=N` with `N > 0`; this catches the session-establish and empty-data gaps `vise check` can't see (see [docs/RUNTIME_SMOKE.md](docs/RUNTIME_SMOKE.md)) |
251
+ | `vise smoke [path] --log <file>` | Assess a captured mount-smoke log into a pass/fail verdict + record evidence. `expect: "populated"` requires `loaded count=N` with `N > 0`; this catches session-establish and empty-data gaps that static checks cannot see |
257
252
  | `vise install-skill --target <host>` | Install the bundled skill into a coding host (see [Quick Start](#quick-start)) |
258
253
  | `vise print-skill` | Print the skill markdown to stdout |
259
254
  | `vise engagement init [path] [--tier ...] [--customer-id ...] [--scope ...]` | Record optional contractual scope metadata |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@amityco/social-plus-vise",
3
- "version": "1.4.3",
3
+ "version": "1.4.4",
4
4
  "description": "Skill-guided deterministic CLI for social.plus SDK integration assistance.",
5
5
  "license": "SEE LICENSE IN LICENSE",
6
6
  "type": "module",