Role i Komendy (Roles and Commands)

Przegląd

System symuluje realny zespół produktowy poprzez zestaw ról AI agents. Każda rola ma specyficzne obowiązki i komendy.

Hierarchia Ról

PRODUCT LAYER
├─ Stakeholder (biznes)
├─ Product Owner (produkt)
└─ Analytic_Business (analiza biznesowa)

DESIGN LAYER
└─ UX_Designer (projektowanie)

TECHNICAL LAYER
├─ Analytic_System (architektura)
├─ Frontend (implementacja UI)
├─ Backend (implementacja API)
├─ Database (bazy danych)
├─ Integration (integracje zewnętrzne)
├─ Migration (migracje danych)
├─ Setup (konfiguracja środowiska)
├─ Deploy (wdrożenia)
└─ Refactor (refaktoryzacja)

TESTING LAYER
├─ Test (testy automatyczne)
├─ QA (quality assurance)
├─ Performance (wydajność)
└─ Accessibility (dostępność)

REVIEW LAYER
├─ Critic (code critic)
├─ Reviewer_Tech (technical review)
├─ Reviewer_Product (product review)
├─ Code-Reviewer (agent - code review)
└─ Debugger (agent - debugowanie)

VERIFICATION LAYER
├─ Verify (weryfikacja końcowa)
└─ Finalize (finalizacja)

BUSINESS LAYER
└─ Business (akceptacja końcowa)

Product Layer

Stakeholder

Odpowiedzialność: Definiuje potrzebę biznesową i cel

Zakres działania:

✅ Inicjuje potrzebę biznesową
✅ Definiuje cel, KPI i priorytet
✅ Dostarcza kontekst „dlaczego"
✅ Może komentować zadanie na etapie discovery
❌ NIE wchodzi w implementację

Komendy: Brak (rola pasywna - dostarcza input)

Przykładowy Input:

markdown

## Stakeholder Input

**Cel biznesowy**: Zwiększyć konwersję o 15% w Q1

**KPI**:
- Conversion rate: 12% → 15%
- User satisfaction: 7.5 → 8.5
- Support tickets: -20%

**Priorytet**: HIGH
**Deadline**: 2025-02-15

**Dlaczego**:
Użytkownicy zgłaszają trudności w znalezieniu ustawień.
Analytics pokazują 45% bounce rate na stronie settings.

Product Owner (PO)

Odpowiedzialność: Główny product owner zadania

Zakres działania:

✅ Prowadzi discovery
✅ Decyduje o zakresie (in / out)
✅ Definiuje user stories i acceptance criteria
✅ Zarządza priorytetami
✅ Akceptuje zadanie produktowo przed przekazaniem do biznesu

Komendy:

/discovery - Przeprowadzenie discovery
/define - Definicja zakresu i wymagań
/prioritize - Ustalenie priorytetów
/accept_product - Akceptacja produktowa

Przykład /discovery:

Input: task.md z ogólnym celem

markdown

# Settings UI Unification

Użytkownicy mają problem ze znalezieniem opcji w menu ustawień.

Output (artifacts/discovery.md):

markdown

# Discovery Report

## User Research
- Przeprowadzono 15 wywiadów z użytkownikami
- 80% zgłasza trudności w nawigacji
- Główny problem: ikony niewidoczne na mobile

## Current State
- Menu settings ma 12 opcji
- Ikony widoczne tylko desktop
- Mobile: tylko tekst

## User Stories
1. Jako użytkownik mobilny chcę widzieć ikony w menu settings
   aby szybciej znaleźć poszukiwaną opcję

2. Jako użytkownik desktop chcę zachować obecny layout
   aby nie tracić wydajności

## Acceptance Criteria
- [ ] Ikony widoczne na wszystkich viewportach
- [ ] Responsive design (desktop, tablet, mobile)
- [ ] Zachowanie istniejącego design systemu
- [ ] Czas ładowania < 2s

## Out of Scope
- Redesign całego menu
- Dodawanie nowych opcji settings
- Zmiana kolejności menu items

Analytic_Business

Odpowiedzialność: Analiza wymagań biznesowych

Zakres działania:

✅ Analizuje wymagania biznesowe
✅ Mapuje procesy i scenariusze
✅ Identyfikuje edge case'y
✅ Wspiera PO w definiowaniu acceptance criteria
✅ Może dodawać krytyki do tasków

Komendy:

/analyze_business - Analiza biznesowa
/refine_requirements - Doprecyzowanie wymagań

Przykład /analyze_business:

Output (artifacts/business_analysis.md):

markdown

# Business Analysis Report

## Process Mapping

### Current Process
1. User opens settings
2. User scrolls looking for option
3. 45% bounce rate (analytics)
4. Support ticket created

### Target Process
1. User opens settings
2. User sees icons immediately
3. User clicks correct option
4. Task completed (< 30s)

## Scenarios

### Happy Path
- Desktop user: Sees icons, clicks, success
- Mobile user: Sees icons, clicks, success

### Edge Cases
1. **Low bandwidth** - Icons may load slowly
   - Solution: Provide text fallback
   - Priority: P1

2. **Screen readers** - Icons need alt text
   - Solution: ARIA labels
   - Priority: P0 (accessibility)

3. **Old browsers** - SVG icons may not render
   - Solution: PNG fallback
   - Priority: P2

## Business Rules
1. Icons must load within 2s (or show text)
2. All icons must have ARIA labels
3. Design system colors must be preserved
4. Mobile icons: min size 24x24px

## Metrics to Track
- Time to complete settings task (before/after)
- Bounce rate on settings page
- Support tickets related to settings

Design Layer

UX_Designer

Odpowiedzialność: Projektowanie user experience

Zakres działania:

✅ Projektuje user flow
✅ Przygotowuje makiety (low / hi-fi)
✅ Definiuje stany, walidacje i edge case'y UX
✅ Przygotowuje handoff dla frontendu

Komendy:

/design - Projektowanie UX
/ux_review - Review UX implementacji

Przykład /design:

Output (artifacts/design_spec.md):

markdown

# UX Design Specification

## User Flow

┌────────────────┐ │ Open Settings │ └───────┬────────┘ │ ▼ ┌────────────────────────┐ │ Settings Menu │ │ [Icon] Dashboard │ │ [Icon] Profile │ │ [Icon] Notifications │ │ [Icon] Privacy │ └────────────────────────┘


## Components

### SettingsMenuItem
**Props**:
- `icon`: IconType (required)
- `label`: string (required)
- `badge`: number | null (optional)
- `onClick`: () => void

**States**:
- Default
- Hover
- Active
- Disabled

**Variants**:
- Desktop (icon + label)
- Mobile (icon + label, stacked)

## Visual Specifications

### Desktop (1920x1080)
- Icon size: 32x32px
- Label: 16px, Regular
- Spacing: 16px between items
- Layout: Horizontal (icon left, label right)

### Mobile (375x812)
- Icon size: 24x24px
- Label: 14px, Regular
- Spacing: 12px between items
- Layout: Vertical (icon top, label bottom)

## Color Palette
- Icon default: #64748B (slate-500)
- Icon hover: #0F172A (slate-900)
- Icon active: #3B82F6 (blue-500)
- Label: #1E293B (slate-800)

## Accessibility
- ARIA labels: Required for all icons
- Keyboard navigation: Tab order follows visual order
- Focus indicators: 2px blue outline
- Min contrast ratio: 4.5:1 (WCAG AA)

## Animations
- Icon hover: scale(1.1) 200ms ease
- Menu item hover: background fade 150ms
- Page transition: slide 300ms ease-out

Technical Layer

Analytic_System (Tech / Architektura)

Odpowiedzialność: Analiza techniczna i architektura

Zakres działania:

✅ Analizuje wpływ na system
✅ Identyfikuje integracje i zależności
✅ Definiuje kontrakty API
✅ Wskazuje ryzyka techniczne

Komendy:

/analyze_system - Analiza systemu
/define_api - Definicja API

Przykład /analyze_system:

Output (artifacts/system_analysis.md):

markdown

# System Analysis Report

## Architecture Impact

### Current Architecture

Frontend (Angular) → API Gateway → Backend (Laravel) ↓ Database


**Changes**: Frontend only (no backend changes required)

### Components Affected
1. **SettingsMenuComponent** (existing) - needs update
2. **MenuIconComponent** (new) - needs creation
3. **SettingsService** (existing) - no changes
4. **AppRoutingModule** (existing) - no changes

## Dependencies

### External
- Angular Material Icons (existing dependency)
- No new external dependencies required

### Internal
1. **Shared Module** - MenuIconComponent will be added here
2. **Design System** - Will use existing colors/spacing
3. **Icon Library** - Will use existing SVG icons

## Technical Risks

### Risk 1: Performance
**Issue**: Loading 12 icons may slow mobile
**Impact**: Medium
**Mitigation**: Lazy load icons below fold
**Priority**: P2

### Risk 2: Browser Compatibility
**Issue**: SVG not supported in IE11
**Impact**: Low (IE11 usage < 1%)
**Mitigation**: PNG fallback
**Priority**: P3

### Risk 3: Bundle Size
**Issue**: +25KB for icon assets
**Impact**: Low
**Mitigation**: Tree-shaking, gzip
**Priority**: P3

## API Contracts

**No API changes required** (frontend-only task)

## Database Impact

**No database changes required**

## Deployment Strategy

1. Deploy frontend changes
2. Monitor error rates (24h)
3. Rollback if error rate > 0.5%
4. Gradual rollout: 10% → 50% → 100%

Frontend_Angular

Odpowiedzialność: Implementacja UI w Angular

Zakres działania:

✅ Implementuje UI zgodnie z designem
✅ Zachowuje kompatybilność z istniejącymi komponentami
✅ Zapewnia Storybook dla komponentów
✅ Integruje frontend z API
✅ Zgłasza braki w designie lub API

Komendy:

/frontend {PATH_DO_SUBTASKA} - Implementacja frontendu

Przykład /frontend:

Input: subtask/P1/todo/frontend_abc123/task.md

markdown

# Implement MenuIcon Component

Create a reusable MenuIcon component according to design spec.

**Design**: /task/artifacts/design_spec.md
**Location**: src/app/shared/components/menu-icon/

Działania:

Tworzy component: ng generate component shared/menu-icon
Implementuje według spec
Dodaje do Storybook
Pisze unit tests
Commituje zmiany

Output (zmiany w kodzie):

typescript

// menu-icon.component.ts
import { Component, Input } from '@angular/core';

export type IconType = 'dashboard' | 'profile' | 'notifications' | 'privacy';

@Component({
  selector: 'app-menu-icon',
  templateUrl: './menu-icon.component.html',
  styleUrls: ['./menu-icon.component.scss']
})
export class MenuIconComponent {
  @Input() icon!: IconType;
  @Input() label!: string;
  @Input() badge?: number | null;
  @Input() disabled = false;
}

Backend_Laravel

Odpowiedzialność: Implementacja API w Laravel

Zakres działania:

✅ Implementuje logikę biznesową
✅ Tworzy i utrzymuje API
✅ Dba o bezpieczeństwo i wydajność
✅ Pisze testy API

Komendy:

/backend {PATH_DO_SUBTASKA} - Implementacja backendu

Przykład /backend:

Input: subtask/P1/todo/backend_def456/task.md

markdown

# Implement User Settings API

Create REST API for user settings management.

**Endpoints**:
- GET /api/v1/settings
- PUT /api/v1/settings/{key}

Działania:

Tworzy migration dla settings table
Tworzy model Settings
Tworzy controller SettingsController
Dodaje routes
Pisze API tests
Commituje zmiany

Output (zmiany w kodzie):

php

// app/Http/Controllers/Api/SettingsController.php
<?php

namespace App\Http\Controllers\Api;

use App\Models\Setting;
use Illuminate\Http\Request;

class SettingsController extends Controller
{
    public function index(Request $request)
    {
        $settings = Setting::where('user_id', $request->user()->id)
            ->get()
            ->keyBy('key')
            ->map->value;

        return response()->json($settings);
    }

    public function update(Request $request, string $key)
    {
        $validated = $request->validate([
            'value' => 'required|string|max:1000'
        ]);

        $setting = Setting::updateOrCreate(
            ['user_id' => $request->user()->id, 'key' => $key],
            ['value' => $validated['value']]
        );

        return response()->json($setting);
    }
}

QA

Odpowiedzialność: Testowanie jakości

Zakres działania:

✅ Pisze testy Playwright i testy API
✅ Testuje zgodność z acceptance criteria
✅ Wykonuje testy regresji
✅ Dostarcza dowody jakości (raporty, screeny, logi)
✅ Może tworzyć follow-up taski gdy znajdzie bugs

Komendy:

/test {PATH_DO_SUBTASKA} - Pisanie i uruchamianie testów
/regression - Testy regresji

Przykład /test:

Input: subtask/P2/todo/test_ghi789/task.md

markdown

# Write E2E Tests for Settings Menu

Test all scenarios from acceptance criteria.

**Scenarios**:
1. Icons visible on desktop
2. Icons visible on mobile
3. Click navigates correctly

Działania:

Tworzy test file: e2e/settings-menu.spec.ts
Implementuje test scenarios
Uruchamia testy lokalnie
Jeśli failują → tworzy follow-up task (bug fix)
Commituje testy

Output (test code):

typescript

// e2e/settings-menu.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Settings Menu', () => {
  test('icons visible on desktop', async ({ page }) => {
    await page.setViewportSize({ width: 1920, height: 1080 });
    await page.goto('/settings');

    const icons = await page.locator('.menu-icon').count();
    expect(icons).toBeGreaterThan(0);

    for (let i = 0; i < icons; i++) {
      const icon = page.locator('.menu-icon').nth(i);
      await expect(icon).toBeVisible();
    }
  });

  test('icons visible on mobile', async ({ page }) => {
    await page.setViewportSize({ width: 375, height: 812 });
    await page.goto('/settings');

    const icons = await page.locator('.menu-icon').count();
    expect(icons).toBeGreaterThan(0);

    for (let i = 0; i < icons; i++) {
      const icon = page.locator('.menu-icon').nth(i);
      await expect(icon).toBeVisible();
    }
  });
});

Jeśli testy failują - tworzy follow-up task:

bash

create_subtask P0 frontend \
  "Fix: Menu icons not visible on mobile" \
  "Test failed: icons not rendering on mobile viewport (375x812). Screenshot: test-failure-mobile.png" \
  "frontend_abc123"

Review Layer

Reviewer_Tech (Tech Lead / Senior)

Odpowiedzialność: Code review techniczny

Zakres działania:

✅ Wykonuje code review
✅ Ocenia jakość architektury
✅ Sprawdza zgodność ze standardami
✅ Może blokować zadanie (tworzy krytyki)

Komendy:

/review_tech - Techniczny code review

Przykład /review_tech:

Output (artifacts/tech_review.md):

markdown

# Technical Review Report

## Code Quality: ✅ APPROVED

### Positive Points
1. ✅ Clean component structure
2. ✅ Proper TypeScript typing
3. ✅ Unit tests coverage: 95%
4. ✅ Follows Angular style guide
5. ✅ Accessibility considerations (ARIA)

### Issues Found

#### Minor Issues (P2)
1. **Magic numbers in styling**
   - File: menu-icon.component.scss:15
   - Issue: Hardcoded `24px` should use design token
   - Suggestion: Use `$icon-size-mobile` variable

2. **Missing error handling**
   - File: settings.service.ts:42
   - Issue: No error handling for API call
   - Suggestion: Add try-catch with user-friendly error

#### Recommendations
1. Consider extracting icon size logic to a directive
2. Add JSDoc comments for public methods
3. Consider lazy loading for icon assets

## Architecture: ✅ APPROVED

- Follows existing patterns
- No new dependencies
- Proper separation of concerns

## Security: ✅ APPROVED

- No security vulnerabilities found
- Input sanitization present
- CSRF protection maintained

## Performance: ✅ APPROVED

- Bundle size impact: +18KB (acceptable)
- No memory leaks detected
- Load time impact: < 100ms

## Final Decision: ✅ APPROVED WITH MINOR SUGGESTIONS

Code can be merged. Minor issues can be addressed in follow-up.

Reviewer_Product

Odpowiedzialność: Product review

Zakres działania:

✅ Weryfikuje zgodność z wymaganiami produktowymi
✅ Sprawdza flow użytkownika end-to-end
✅ Rekomenduje akceptację lub poprawki
✅ Może tworzyć follow-up taski gdy znajdzie problemy

Komendy:

/reviewer_product - Product review

Przykład /reviewer_product:

Output (artifacts/product_review.md):

markdown

# Product Review Report

## Requirements Verification

### Original Requirements
- [x] Wszystkie ikony widoczne na desktop
- [x] Wszystkie ikony widoczne na mobile
- [x] Responsive design
- [x] Testy Playwright

**Status**: ✅ ALL REQUIREMENTS MET

## User Flow Testing

### Desktop Flow (1920x1080)
1. Open settings ✅
2. See icons immediately ✅
3. Hover shows animation ✅
4. Click navigates correctly ✅

**Result**: ✅ PASSED

### Mobile Flow (375x812)
1. Open settings ✅
2. Icons visible BUT icons too small ⚠️
3. Click works ✅
4. Scrolling smooth ✅

**Result**: ⚠️ PASSED WITH WARNING

### Tablet Flow (768x1024)
1. Open settings ✅
2. Icons visible ✅
3. Layout adapts correctly ✅

**Result**: ✅ PASSED

## Issues Found

### Minor UX Issues (P2)
1. **Mobile icon size**
   - Current: 24px
   - Recommended: 28px (better touch target)
   - Screenshot: mobile-icon-size.png
   - Can be addressed in follow-up

2. **Missing loading state**
   - Icons appear instantly (good)
   - But no loading state if slow connection
   - Recommendation: Add skeleton loader

## Acceptance Criteria Check

- [x] Icons visible on all viewports
- [x] Responsive design works
- [x] Design system preserved
- [x] Tests passing
- [x] Build successful

**Status**: ✅ 5/5 PASSED

## Final Decision: ✅ APPROVED

Product can be shipped. Minor UX improvements can be follow-up.

## Screenshots Evidence
- desktop-settings-final.png ✅
- mobile-settings-final.png ⚠️ (icon size)
- tablet-settings-final.png ✅

Business Layer

Business

Odpowiedzialność: Ostateczna akceptacja biznesowa

Zakres działania:

✅ Odbiera zadanie na końcu procesu
✅ Weryfikuje realizację celu biznesowego
✅ Oczekuje dowodów, nie deklaracji:
- Demo
- Raporty testów
- Metryki / KPI
✅ Podejmuje decyzję o akceptacji lub zmianach

Komendy:

/accept_business - Akceptacja biznesowa
/request_changes - Request zmian

Przykład /accept_business:

Input: Wszystkie raporty + demo + metryki

Output (artifacts/business_acceptance.md):

markdown

# Business Acceptance Report

## Goal Verification

**Original Goal**: Zwiększyć konwersję o 15% w Q1
**Current Status**: In progress (monitoring required)

## KPI Baseline (Before)
- Conversion rate: 12%
- User satisfaction: 7.5
- Support tickets: 120/month
- Bounce rate on settings: 45%

## Evidence Reviewed

### 1. Demo ✅
- Live demo on staging: PASSED
- All features working as expected
- UX smooth and intuitive

### 2. Test Reports ✅
- Unit tests: 95% coverage
- E2E tests: All passed
- Manual testing: No bugs found

### 3. Visual Evidence ✅
- Screenshots: 15 viewports
- Desktop, mobile, tablet: All OK
- Icons visible and accessible

### 4. Performance ✅
- Load time: 1.8s (target: < 2s)
- Bundle size: +18KB (acceptable)
- No performance degradation

## User Feedback (Beta Testing)

**Beta users**: 50 users, 7 days
- 92% positive feedback
- "Much easier to find settings" - 15 comments
- "Icons help a lot" - 23 comments
- "Mobile experience improved" - 8 comments

**Issues reported**: 1
- Icon size on mobile (already noted in product review)

## Business Decision

### ✅ APPROVED FOR PRODUCTION

**Justification**:
- All acceptance criteria met
- Positive user feedback
- No blocking issues
- Expected impact on KPI realistic

**Next Steps**:
1. Deploy to production (gradual rollout)
2. Monitor KPIs for 30 days
3. Measure conversion rate change
4. Address minor icon size issue in Q1

**Follow-up**:
- Create task for mobile icon size optimization (P3)
- Schedule KPI review meeting (2025-02-15)

Dynamic Follow-up Creation (Tworzenie Subtasków)

Wszystkie role implementacyjne i weryfikacyjne mogą dynamicznie tworzyć subtaski podczas wykonywania zadania. Jest to kontrolowane przez parametr can-create-subtasks: true w YAML frontmatter każdej komendy.

Role które mogą tworzyć subtaski:

Warstwa	Role	Kiedy tworzą
Implementacja	frontend, backend, database	Gdy potrzebują zmian w innym obszarze
Testy	test, qa, tester	Gdy testy failują, brak pokrycia
Review	critic, reviewer_tech, reviewer_product	Problemy jakości, UX, architektura
Weryfikacja	verify, accessibility, performance	Problemy dostępności, wydajności
Analiza	analytic_business, analytic_system	Brakujące wymagania, integracje
Infrastruktura	setup, deploy, integration, migration	Problemy środowiska, konfiguracji
Biznes	po, business, finalize	Brakujące wymagania, akceptacja
Agenci	debugger, code-reviewer	Znalezione bugi, problemy jakości

Typowe scenariusze:

Rola	Kiedy tworzy	Priority
Frontend	Brak endpoint API	P0
Backend	Brakująca migracja DB	P0
Reviewer_Tech	Problemy bezpieczeństwa	P0
Reviewer_Product	Krytyczne problemy UX	P0/P1
Test/QA	Testy failują	P0
Performance	Problemy wydajnościowe	P1/P2
Accessibility	Brak WCAG compliance	P1/P2
Debugger	Znaleziony bug	P0/P1

Składnia tworzenia subtasku:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "PRIORITY" \
  "ROLE" \
  "$(openssl rand -hex 4)" \
  "TITLE" \
  "OBJECTIVE" \
  "DEPENDENCIES"

Parametry:

TASK_ID - ID głównego zadania (np. DEV-1234)
PRIORITY - Priorytet: P0, P1, P2, P3
ROLE - Rola wykonująca: frontend, backend, test, qa, etc.
HEX_ID - Unikalny 8-znakowy hex ID (generuj: $(openssl rand -hex 4))
TITLE - Krótki tytuł subtasku
OBJECTIVE - Szczegółowy opis celu
DEPENDENCIES - Lista zależności (ID subtasków) lub "None"

Przykłady:

Frontend potrzebuje endpoint API:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "P0" \
  "backend" \
  "$(openssl rand -hex 4)" \
  "Create GET /api/users/:id/profile endpoint" \
  "Frontend UserProfile component needs endpoint returning {avatar, bio, settings}. Currently 404." \
  "None"

Reviewer znalazł problem bezpieczeństwa:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "P0" \
  "backend" \
  "$(openssl rand -hex 4)" \
  "Fix SQL injection vulnerability in search endpoint" \
  "User input in /api/search is not sanitized. Use parameterized queries." \
  "None"

Test failuje - brak walidacji:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "P1" \
  "frontend" \
  "$(openssl rand -hex 4)" \
  "Add form validation for email field" \
  "Registration form accepts invalid emails. Add client-side validation with error messages." \
  "backend_a1b2c3d4"

Best Practices

1. Jedna rola = Jeden concern

❌ Źle: Frontend robi również code review

markdown

- Implementuj komponent
- Zrób code review
- Napisz testy

✅ Dobrze: Oddzielne role

markdown

- Frontend: Implementuj komponent
- Test: Napisz testy
- Reviewer_Tech: Code review

2. Zachowaj kontekst między rolami

Każda rola powinna mieć dostęp do artifacts poprzednich ról:

PO → /discovery → artifacts/discovery.md
                     ↓
UX_Designer → /design → artifacts/design_spec.md
                           ↓
Frontend → /frontend → używa design_spec.md

3. Używaj follow-up dla bugs

Zamiast failować cały task - stwórz follow-up:

bash

# Gdy test failuje
if ! npm test; then
  create_subtask P0 frontend \
    "Fix: Unit tests failing" \
    "$(npm test 2>&1 | tail -20)" \
    "frontend_component"
fi

Role i Komendy (Roles and Commands)

Przegląd

Hierarchia Ról

Product Layer

Stakeholder

Product Owner (PO)

Analytic_Business

Design Layer

UX_Designer

Technical Layer

Analytic_System (Tech / Architektura)

Frontend_Angular

Backend_Laravel

QA

Review Layer

Reviewer_Tech (Tech Lead / Senior)

Reviewer_Product

Business Layer

Business

Dynamic Follow-up Creation (Tworzenie Subtasków)

Role które mogą tworzyć subtaski:

Typowe scenariusze:

Składnia tworzenia subtasku:

Przykłady:

Best Practices

1. Jedna rola = Jeden concern

2. Zachowaj kontekst między rolami

3. Używaj follow-up dla bugs

Changelog

v2.0 - Dynamic Follow-up

v1.0 - Initial Roles

Role i Komendy (Roles and Commands) ​

Przegląd ​

Hierarchia Ról ​

Product Layer ​

Stakeholder ​

Product Owner (PO) ​

Analytic_Business ​

Design Layer ​

UX_Designer ​

Technical Layer ​

Analytic_System (Tech / Architektura) ​

Frontend_Angular ​

Backend_Laravel ​

QA ​

Review Layer ​

Reviewer_Tech (Tech Lead / Senior) ​

Reviewer_Product ​

Business Layer ​

Business ​

Dynamic Follow-up Creation (Tworzenie Subtasków) ​

Role które mogą tworzyć subtaski: ​

Typowe scenariusze: ​

Składnia tworzenia subtasku: ​

Przykłady: ​

Best Practices ​

1. Jedna rola = Jeden concern ​

2. Zachowaj kontekst między rolami ​

3. Używaj follow-up dla bugs ​

Changelog ​

v2.0 - Dynamic Follow-up ​

v1.0 - Initial Roles ​

Role i Komendy (Roles and Commands)

Przegląd

Hierarchia Ról

Product Layer

Stakeholder

Product Owner (PO)

Analytic_Business

Design Layer

UX_Designer

Technical Layer

Analytic_System (Tech / Architektura)

Frontend_Angular

Backend_Laravel

QA

Review Layer

Reviewer_Tech (Tech Lead / Senior)

Reviewer_Product

Business Layer

Business

Dynamic Follow-up Creation (Tworzenie Subtasków)

Role które mogą tworzyć subtaski:

Typowe scenariusze:

Składnia tworzenia subtasku:

Przykłady:

Best Practices

1. Jedna rola = Jeden concern

2. Zachowaj kontekst między rolami

3. Używaj follow-up dla bugs

Changelog

v2.0 - Dynamic Follow-up

v1.0 - Initial Roles