@jaimevalasek/aioson 1.7.0 → 1.8.0

package/template/.aioson/skills/marketing/vsl-craft.md

@@ -0,0 +1,385 @@
+---
+name: vsl-craft
+description: Video Sales Letter production skill — script structure, hook formulas, retention techniques, testing methodology, and production specs. Loaded by @copywriter when Mode 5 (VSL) is active.
+---
+
+# VSL Craft — Video Sales Letter Production
+
+## When to load this skill
+
+- User requests a VSL script
+- User requests a video sales page (page with embedded sales video)
+- User requests an advertorial video
+- @copywriter Mode 5 is activated
+- Squad executor with VSL deliverable
+
+---
+
+## 1. What is a VSL?
+
+A Video Sales Letter is a scripted video (typically 10-45 minutes) designed to convert cold traffic into buyers. It replaces the live salesperson with a pre-recorded, optimized sales presentation.
+
+**Key differences from a written sales page:**
+- The viewer can't scan — they must watch sequentially
+- Retention is everything — if they leave at minute 3, the offer at minute 20 never gets seen
+- Audio + visual = two channels to reinforce the message
+- Pacing, pauses, and emotional tone are scripted, not left to chance
+
+---
+
+## 2. VSL formats
+
+### 2.1 Traditional VSL (horizontal)
+- 16:9 format, presenter or slides
+- Duration: 15-45 minutes
+- Best for: sophisticated offers, higher ticket (R$297+), cold traffic from YouTube/Facebook
+- Production: can be "ugly" (slides only) or "cinematic" (B-roll, editing)
+
+### 2.2 Vertical VSL (mobile-native)
+- 9:16 format, looks like organic content
+- Duration: 3-15 minutes
+- Best for: TikTok/Reels traffic, lower ticket, younger audiences
+- Production: phone-filmed, fast cuts, captions mandatory
+
+### 2.3 Hybrid (advertorial + VSL)
+- Written advertorial page with embedded video at the mechanism section
+- The text does Act 1-2, the video does Act 3-5
+- Best for: sophisticated audiences who want to read before watching
+
+---
+
+## 3. The VSL script structure (5 Acts adapted for video)
+
+### Act 1 — The Hook (0:00 to 0:30)
+
+**Goal:** Stop the scroll and keep them watching for the next 30 seconds.
+
+**The 3-second rule:** If the first 3 seconds aren't arresting, the viewer leaves.
+
+**Hook formulas for VSL:**
+
+**Formula 1: The Discovery Hook**
+> "What you're about to see in the next [X] minutes could change the way you [desired outcome] forever. I'm going to show you [specific discovery] that [specific proof]."
+
+**Formula 2: The Proof-First Hook**
+> "[Name], [age], from [city], lost [specific result] in [specific time]. And she did it without [painful thing]. Today I'm going to show you exactly how — and why it works even if [objection]."
+
+**Formula 3: The Paradox Hook**
+> "Why do [specific group] [achieve result] while [audience group] [fail despite effort]? The answer has nothing to do with [obvious thing] — and everything to do with [curiosity element]."
+
+**Formula 4: The Warning Hook**
+> "If you're [doing common thing], stop immediately. A [authority/study] just revealed that [counterintuitive finding] — and it's costing you [consequence]. Stay with me for [time] and I'll show you [solution]."
+
+**Formula 5: The Story Hook**
+> "Last [day], [specific person] sent me this message: [screenshot/quote]. [X time] ago, they were [painful situation]. Today they [desired outcome]. This is their story — and it starts with [curiosity element]."
+
+**Anti-pattern hooks:**
+- "Hey everyone, welcome to my channel..." → Zero curiosity
+- "In this video I'm going to talk about..." → Passive, no hook
+- "So, I've been getting a lot of questions about..." → About you, not them
+
+### Act 2 — The Background (0:30 to 3:00)
+
+**Goal:** Build authority and emotional connection quickly.
+
+**For expert-led VSL:**
+> "[Credentials in one sentence]. But what matters more than my degrees is this: I've helped [specific number] of people [achieve result], and what I discovered along the way is the reason you're watching this video."
+
+**For avatar transformation:**
+> "I know what it's like to [specific pain]. [Time] ago, I was [painful situation — specific details]. I tried [what they've tried]. Nothing worked. Until [discovery moment]."
+
+**Key rule:** Act 2 must be SHORT in a VSL. On a written page, you can have a long background section. On video, 1-2 minutes max. Get to the mechanism fast.
+
+### Act 3 — The Mechanism (3:00 to 12:00)
+
+**Goal:** Create the "Aha!" moment. This is where the One Belief is built.
+
+**Structure:**
+
+**Part A — Why nothing else worked (2-4 minutes)**
+1. Name what they've tried (validate their experience)
+2. Reveal the hidden reason it failed (the enemy — not them)
+3. Use a visual metaphor or diagram to make the concept tangible
+
+**Part B — How [Mechanism Name] works (3-5 minutes)**
+1. Introduce the mechanism by name
+2. Explain it at surface level (simple enough for a 12-year-old)
+3. Show ONE proof point (study, case study, demonstration)
+4. Use B-roll or diagrams to illustrate — never just talk over static slides for more than 30 seconds
+
+**Retention techniques for Act 3:**
+- **Pattern interrupt every 60-90 seconds:** Change the visual, show a diagram, cut to B-roll, display a quote
+- **Open loops:** "In a moment I'll show you the third step — but first you need to understand why..."
+- **Micro-fascinations:** Drop curiosity bullets throughout: "The ingredient I'm about to mention is in 90% of Brazilian homes but nobody knows it does THIS..."
+- **Density escalation:** Each minute should be MORE interesting than the last, not less
+
+### Act 4 — The Offer (12:00 to 18:00)
+
+**Goal:** Transition from education to sale without breaking trust.
+
+**The transition bridge:**
+> "So now you understand WHY [mechanism] works and HOW it produces [result]. The question is: how do YOU implement it? That's exactly why I created [Product Name]."
+
+**VSL-specific offer rules:**
+- Never call it a "course" — use Protocol, System, Blueprint, Accelerator
+- Show each component visually (mockup, icon, or slide)
+- Read the fascinations with enthusiasm — pacing matters
+- Pause after stating the price — let it sink in
+- Show the guarantee prominently (text on screen + verbal)
+
+**Reference:** `.aioson/skills/marketing/references/offer-structure.md`
+
+### Act 5 — The Close (18:00 to 22:00)
+
+**Goal:** Push the fence-sitters over the edge.
+
+**The Two Paths technique (optimized for video):**
+> "Right now, you're at a fork in the road.
+> [Pause — 2 seconds]
+> Path one: you close this video. You go back to [specific pain]. Tomorrow feels the same as today. Next month, same. Next year...
+> [Pause — 3 seconds]
+> Path two: you click the button below. You start [Product Name] today. In [timeframe], you [specific visualizable result].
+> [Pause — 2 seconds]
+> Which path makes more sense?"
+
+**Recovery techniques (the "Kenyan Village" strategy):**
+- **Pause thumbnail:** When the viewer pauses, a thumbnail appears with a hook to resume
+- **Exit-intent popup:** On the page, when cursor moves to close — offer a discount or bonus
+- **Post-VSL autoplay:** After the main VSL, play a shorter 3-minute "for those still deciding" video
+- **SMS/email retargeting:** Capture email early (before VSL starts) and send follow-up sequence
+
+---
+
+## 4. VSL script format
+
+When writing a VSL script, use this format:
+
+```markdown
+# VSL Script: [Product Name]
+
+## Metadata
+- Duration target: [X] minutes
+- Format: Horizontal / Vertical
+- Traffic temperature: Cold / Warm / Hot
+- One Belief: "[New Opportunity] is the key to [Benefit] through [Mechanism]"
+- Awareness level: [1-5]
+
+---
+
+## ACT 1 — HOOK (0:00–0:30)
+
+### VISUAL:
+[What appears on screen]
+
+### AUDIO:
+[What is said — scripted word-for-word]
+
+### NOTES:
+[Production notes: B-roll, text overlay, music cue]
+
+---
+
+## ACT 2 — BACKGROUND (0:30–3:00)
+
+### VISUAL:
+[Screen description]
+
+### AUDIO:
+[Script]
+
+### NOTES:
+[Production notes]
+
+---
+
+## ACT 3 — MECHANISM (3:00–12:00)
+
+### 3A — Why nothing else worked
+
+#### VISUAL:
+[Screen]
+
+#### AUDIO:
+[Script]
+
+#### PATTERN INTERRUPT at [timestamp]:
+[Visual change / diagram / B-roll description]
+
+### 3B — How [Mechanism] works
+
+#### VISUAL:
+[Screen]
+
+#### AUDIO:
+[Script]
+
+#### PROOF POINT:
+[Study / case study / demonstration]
+
+---
+
+## ACT 4 — OFFER (12:00–18:00)
+
+### TRANSITION:
+
+#### AUDIO:
+[Bridge sentence]
+
+### COMPONENT STACK:
+
+#### VISUAL:
+[Mockup / slide of each component]
+
+#### AUDIO:
+[Component name, benefit, value, fascination]
+
+### PRICE REVEAL:
+
+#### VISUAL:
+[Anchoring → crossed out prices → final price]
+
+#### AUDIO:
+[Not paying X. Not even Y. Today: Z. Reason why.]
+
+### GUARANTEE:
+
+#### VISUAL:
+[Guarantee badge / text on screen]
+
+#### AUDIO:
+[Full guarantee statement]
+
+---
+
+## ACT 5 — CLOSE (18:00–22:00)
+
+### TWO PATHS:
+
+#### AUDIO:
+[Path 1 → Path 2 → Which makes more sense?]
+
+### FINAL CTA:
+
+#### VISUAL:
+[Button, URL, QR code on screen]
+
+#### AUDIO:
+[Click the button below / link in description]
+
+### RECOVERY ELEMENTS:
+- Pause thumbnail text: [text]
+- Exit-intent offer: [discount/bonus]
+- Post-VSL summary video: [Y/N]
+```
+
+---
+
+## 5. Testing methodology
+
+### Phase 1 — Validate the thesis (before production)
+Create an "ugly" VSL:
+- White background, black text on slides
+- Presenter reads from teleprompter (or text-to-speech for testing)
+- No B-roll, no editing, no music
+- Duration: 10-15 minutes (condensed version)
+
+Run R$500-R$1,000 in cold traffic. Measure:
+- **Hook retention:** % watching past 30 seconds (target: >50%)
+- **Mechanism retention:** % watching past Act 3 (target: >25%)
+- **Offer conversion:** % who reach offer AND click CTA (target: >2%)
+
+If the ugly version converts → invest in production.
+If it doesn't → rewrite the script before spending on video production.
+
+### Phase 2 — Optimize the hook
+Create 3-5 hook variations (first 30 seconds only).
+Run equal traffic to each. The winning hook gets 2-3x more budget.
+
+**Hook metrics:**
+- 3-second retention rate
+- 15-second retention rate
+- 30-second retention rate
+
+### Phase 3 — Scale with production
+Once the script is validated:
+- Add B-roll and visual elements
+- Professional audio recording
+- Add pattern interrupts and visual variety
+- Consider vertical format for mobile-first traffic
+
+---
+
+## 6. VSL page structure
+
+The page that hosts the VSL should be minimal:
+
+```html
+<!-- Above the fold — ONLY the video -->
+<section class="vsl-hero">
+  <div class="video-container">
+    <!-- Video player (VTurb, Wistia, or custom) -->
+    <!-- CTA button appears ONLY after offer section plays -->
+  </div>
+</section>
+
+<!-- Below the fold — revealed after video plays past offer -->
+<section class="vsl-offer">
+  <!-- Component stack (text version of what's in the video) -->
+  <!-- Guarantee -->
+  <!-- CTA button -->
+  <!-- FAQ -->
+  <!-- Testimonials -->
+</section>
+```
+
+**Key rules:**
+- **No navigation menu** — remove all escape routes
+- **CTA button hidden until the offer section plays** — don't let them see the price before the mechanism
+- **Video auto-plays on mute with captions** — most mobile traffic has sound off
+- **Exit-intent popup** — "Wait! Before you go..." with a discount or bonus
+- **Timer optional** — only if the offer has a real deadline
+
+---
+
+## 7. Production specifications
+
+### Audio
+- Clear, professional recording (condenser mic, treated room)
+- Pacing: 150-170 words per minute (conversational speed)
+- Consider 1.1x-1.3x playback speed for higher engagement
+- Music: subtle background only, never competing with voice
+
+### Video
+- Resolution: minimum 1080p
+- B-roll: 2-3 second clips every 60-90 seconds in Act 3
+- Text overlays: key claims and proof points on screen while spoken
+- Captions: always (auto-generated + manually corrected)
+
+### Hosting
+- VTurb (Brazilian market — best heatmap and button reveal features)
+- Wistia (international — CTA tools built in)
+- Custom player (maximum control — no platform branding)
+
+---
+
+## 8. Conditional reference loading
+
+When writing a VSL script, the @copywriter agent should load:
+
+| Phase | Load |
+|---|---|
+| Research | `pms-research.md` + `market-intelligence.md` |
+| Script — hook | `one-belief.md` + `patterns.md` (headline formulas adapt to hooks) |
+| Script — mechanism | `five-acts.md` (Acts 3 focus) |
+| Script — offer | `offer-structure.md` + `fascinations.md` |
+| Script — validation | `anti-patterns.md` |
+
+---
+
+## 9. Output contract
+
+VSL script saves to: `.aioson/context/vsl-script-{slug}.md`
+VSL page spec saves to: `.aioson/context/vsl-page-{slug}.md` (if page design is needed)
+
+If invoked from @ux-ui: return the page spec for visual implementation.
+If invoked from a squad: save to the squad's output directory.

package/template/.aioson/skills/process/aioson-spec-driven/references/pm.md

@@ -0,0 +1,30 @@
+# Spec-Driven Reference — @pm
+
+> Router file. Do not duplicate logic from the generic references — load those directly.
+
+## Which references to load for backlog and delivery planning
+
+### Always load when this skill is active
+
+- `approval-gates.md` — @pm owns Gate C; use it to know exactly what must be true before `phase_gates.plan` can be set to `approved` and before handing off to @dev or @orchestrator
+- `classification-map.md` — use to calibrate sprint sizing and decide how many delivery phases are appropriate for MICRO/SMALL/MEDIUM
+
+### Load when plan structure is ambiguous
+
+- `artifact-map.md` — use to understand which artifacts @pm may read (prd, requirements, spec, architecture) vs. which it must not overwrite (@analyst's requirements, @architect's architecture)
+- `maintenance-and-state.md` — use when retaking a sprint session or checking if a spec-{slug}.md checkpoint needs updating before continuing
+
+### Do not load for @pm
+
+- `hardening-lane.md` — @pm receives hardened input from @product and @analyst; if input is still vague, send it back upstream, do not harden it yourself
+- `qa.md` — Gate D belongs to @qa, not @pm
+
+## Behavioral notes for @pm under SDD
+
+- @pm is the **Gate C owner** — the plan is not complete until `spec-{slug}.md` has `phase_gates.plan: approved` and `implementation-plan-{slug}.md` (if MEDIUM) has `status: approved`
+- Gate C is **blocking in MEDIUM** — @dev and @orchestrator must not execute without Gate C passing
+- Gate C is **informational in SMALL** — flag if the plan looks thin, but do not block
+- Gate C is **skipped in MICRO** — @dev reads prd.md directly; @pm does not run for MICRO
+- ACs produced by @pm must match or extend the ACs in `conformance-{slug}.yaml` when it exists — never contradict the analyst's behavioral contracts
+- @pm adds delivery phases and prioritization; it does NOT rewrite Vision, Problem, Users, or Flows — those belong to @product
+- At session end, always tell the user explicitly: "Gate C passed — activate [@orchestrator / @dev]" OR "Gate C blocked — [reason]"

package/template/.aioson/skills/process/secure-tdd/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: secure-tdd
+description: Process skill for adversarial TDD in security-sensitive features. Load after aioson-spec-driven when classification and attack surface justify it.
+activation: |
+  You are now running the secure-tdd process. Confirm the feature classification and attack surface, load only the stack reference you need, write adversarial tests first, then implement production code.
+---
+
+# Skill: secure-tdd
+
+> Process skill. Adversarial tests before production code.
+> Load this file first. Then load only the stack reference you need.
+
+## When to use
+
+Load this skill only after the normal feature workflow is already active.
+
+- **MEDIUM:** load when the feature has auth, ownership, money, uploads, external URLs, secrets/credentials, or sensitive storage boundaries.
+- **SMALL:** optional reduced mode for the same surfaces.
+- **MICRO:** do not auto-load.
+
+This skill complements `aioson-spec-driven`. It never replaces it.
+
+## Loading order
+
+1. Load `.aioson/skills/process/aioson-spec-driven/SKILL.md` first when the feature is spec-driven.
+2. Read the current `requirements-{slug}.md`, `spec-{slug}.md`, and `architecture.md`.
+3. Load `secure-tdd/SKILL.md`.
+4. Load only one stack reference:
+   - `references/node-express.md`
+   - `references/nextjs.md`
+5. If your stack is not covered by a full v1 reference, read `references/planned-stacks.md` for the minimal fallback.
+
+## Goal
+
+Make `@dev` write the security-sensitive tests first, before implementation, for the attack paths most likely to regress:
+
+- auth bypass
+- IDOR / ownership breaks
+- race conditions / double-submit
+- server-side validation gaps
+- upload validation gaps
+- unsafe external URL handling
+- auth enumeration / rate limiting gaps
+
+## Core rule
+
+Frontend is never the authority.
+Validation, authorization, limits, and sensitive state rules must be enforced server-side.
+
+## Adversarial loop
+
+1. Confirm the sensitive surface from requirements or the Attack Surface Map.
+2. Map the surface to the relevant controls:
+   - `SEC-SBD-01` input limits
+   - `SEC-SBD-02` upload validation
+   - `SEC-SBD-03` ownership / IDOR / auth bypass
+   - `SEC-SBD-04` race condition / atomicity
+   - `SEC-SBD-06` external URL sanitization
+   - `SEC-SBD-08` auth enumeration / rate limiting
+3. Write the minimum failing adversarial tests first.
+4. Implement only enough production code to make those tests pass.
+5. Re-run the tests immediately.
+6. Record in `spec-{slug}.md` which attack classes are now covered.
+
+`SEC-SBD-05` remains primarily tool-first via `security:scan`. Mention it in implementation decisions when relevant, but do not turn this skill into a secrets-scanning checklist.
+
+## Output contract
+
+When this skill is active, `@dev` should produce:
+
+- at least one adversarial test per relevant sensitive surface
+- a short note in `spec-{slug}.md` listing the covered attack classes
+- no new product rules beyond what requirements and architecture already define
+
+## Reduced mode for SMALL
+
+For SMALL features:
+
+- choose only the highest-risk surfaces
+- prefer 1-2 adversarial tests over a full matrix
+- do not block implementation just to expand the suite
+
+## Non-goals
+
+- do not invoke `@pentester`
+- do not emit runtime events
+- do not create CLI commands
+- do not auto-generate large prompt libraries
+- do not duplicate the baseline rule prose
+
+## References available
+
+| File | Load when |
+|---|---|
+| `references/node-express.md` | Implementing Node / Express or service-style Node boundaries |
+| `references/nextjs.md` | Implementing Next.js route handlers, server actions, or server-side validation |
+| `references/planned-stacks.md` | The target stack is Laravel, Django, Rails, FastAPI, or another non-v1 stack |

package/template/.aioson/skills/process/secure-tdd/references/nextjs.md

@@ -0,0 +1,81 @@
+# secure-tdd reference: Next.js
+
+Use this when the feature runs on Next.js route handlers, server actions, or server-side validation flows.
+
+## Preferred runners
+
+- Vitest
+- Testing Library
+- direct assertions on route handlers or server actions when available
+
+## Write first
+
+Start with failing tests that prove the server side rejects forged or cross-user behavior even if the UI looks correct.
+
+Priority order:
+1. auth bypass in route handlers or server actions
+2. forged payload that bypasses UI constraints
+3. IDOR / ownership checks on resource fetch or mutation
+4. unsafe redirect / external URL handling
+5. optimistic UI or double-submit that must not create duplicate critical state
+
+## Minimum patterns
+
+### Server-side validation independent of UI
+
+```tsx
+it('rejects forged payloads on the server', async () => {
+  const res = await POST(new Request('http://test.local/api/resources', {
+    method: 'POST',
+    body: JSON.stringify({ title: 'x'.repeat(10000) })
+  }));
+  expect(res.status).toBe(422);
+});
+```
+
+### Auth / ownership
+
+```tsx
+it('blocks access to another users resource', async () => {
+  const res = await GET(
+    new Request('http://test.local/api/resources/foreign-id'),
+    { params: { id: 'foreign-id' } }
+  );
+  expect([401, 403]).toContain(res.status);
+});
+```
+
+### External URL sanitization
+
+```tsx
+it('rejects unsafe redirect targets', async () => {
+  const res = await POST(new Request('http://test.local/api/redirects', {
+    method: 'POST',
+    body: JSON.stringify({ target: 'javascript:alert(1)' })
+  }));
+  expect(res.status).toBe(422);
+});
+```
+
+### Double-submit / optimistic UI distrust
+
+Write a test proving the server allows only one critical mutation even if the client sends duplicates quickly.
+
+## Control mapping
+
+- `SEC-SBD-01`: route handler / action validation
+- `SEC-SBD-03`: auth bypass / ownership
+- `SEC-SBD-04`: duplicate mutation / optimistic UI distrust
+- `SEC-SBD-06`: unsafe URL / redirect target
+- `SEC-SBD-08`: auth messaging / rate-limiting when applicable
+
+## Core reminder
+
+UI affordances are not evidence.
+Server actions, route handlers, and backend services must enforce the rule.
+
+## Avoid
+
+- testing only component rendering for a security-sensitive feature
+- assuming hidden fields or disabled buttons are protection
+- skipping server-action tests because the page already validates input

package/template/.aioson/skills/process/secure-tdd/references/node-express.md

@@ -0,0 +1,91 @@
+# secure-tdd reference: Node / Express
+
+Use this when the feature runs on Node.js request handlers, Express routes, or service boundaries tested with `node:test`.
+
+## Preferred runners
+
+- `node:test`
+- `supertest` when the project already exposes an HTTP app
+
+If the project is not HTTP-based, keep the same adversarial logic at the boundary-function level.
+
+## Write first
+
+Start with the smallest set of failing tests that proves the server rejects unsafe behavior.
+
+Priority order:
+1. auth bypass / missing auth
+2. cross-user access (IDOR / ownership)
+3. invalid payload beyond server-side limits
+4. unsafe external URL or redirect target
+5. concurrent mutation / race / double-submit when the feature mutates critical state
+
+## Minimum patterns
+
+### Auth bypass / ownership
+
+Write a test that proves user A cannot read, mutate, or delete user B's resource.
+
+```js
+it('returns 403 when accessing another users resource', async () => {
+  const token = await loginAs(userA);
+  const res = await request(app)
+    .get(`/api/resources/${userBResource.id}`)
+    .set('Authorization', `Bearer ${token}`);
+  assert.equal(res.status, 403);
+});
+```
+
+### Server-side validation
+
+Write a test that sends a forged payload bigger or riskier than the UI should allow.
+
+```js
+it('rejects payloads that exceed server-side limits', async () => {
+  const res = await request(app)
+    .post('/api/resources')
+    .send({ title: 'x'.repeat(10_000) });
+  assert.equal(res.status, 422);
+});
+```
+
+### External URL sanitization
+
+Write a test that sends an unsafe URL and expects rejection or strict allowlisting.
+
+```js
+it('rejects unsafe external urls', async () => {
+  const res = await request(app)
+    .post('/api/redirects')
+    .send({ target: 'javascript:alert(1)' });
+  assert.equal(res.status, 422);
+});
+```
+
+### Race condition / double-submit
+
+When the feature changes critical state, write two competing calls and assert one of them is rejected or serialized correctly.
+
+```js
+it('prevents duplicate critical mutations under concurrency', async () => {
+  const [a, b] = await Promise.all([
+    request(app).post('/api/refunds').send({ paymentId }),
+    request(app).post('/api/refunds').send({ paymentId })
+  ]);
+  assert.equal([a.status, b.status].filter((s) => s === 200).length, 1);
+});
+```
+
+## Control mapping
+
+- `SEC-SBD-01`: payload size / field limit tests
+- `SEC-SBD-03`: auth bypass and IDOR tests
+- `SEC-SBD-04`: concurrency / double-submit tests
+- `SEC-SBD-06`: external URL rejection / allowlist tests
+- `SEC-SBD-08`: generic auth error / rate-limiting tests when applicable
+
+## Avoid
+
+- trusting frontend validation as evidence
+- writing only happy-path tests for sensitive endpoints
+- creating broad fixtures when a narrow reproduction is enough