Paweł Łukasiewicz: programista blogger
Paweł Łukasiewicz
2026-03-03
Paweł Łukasiewicz: programista blogger
Paweł Łukasiewicz
2026-03-03
Udostępnij Udostępnij Kontakt
Bonus: od pustego folderu do PR w 45 minut

Przez piętnaście wpisów omawialiśmy koncepty, mechanizmy i pliki konfiguracyjne. Teraz robimy to wszystko razem – od zera – budując realną, małą aplikację TaskFlow API. Będziesz prowadzony krok po kroku: co kliknąć, co wpisać, czego się spodziewać. Otwórz ten wpis na drugim ekranie i rób razem ze mną.

🎫 Jakiego planu potrzebujesz?

Wpis ma dwa tryby – wybierz swój:

FREE Copilot Free / dowolny plan Agent mode w VS Code. Ty inicjujesz sesję, agent implementuje lokalnie, widzisz zmiany w edytorze w czasie rzeczywistym. Działa dla każdego kto ma konto GitHub.
PRO / STUDENT Copilot Pro lub wyżej Coding Agent na GitHub.com. Przypisujesz issue, agent pracuje autonomicznie w Actions, wracasz do gotowego PR. Najbardziej spektakularny tryb.

Kroki 1–4 (setup) są identyczne dla obu. Od Kroku 5 zaznaczam FREE i PRO gdzie ścieżki się rozchodzą.

Co zbudujemy: TaskFlow API – REST API do zarządzania projektami i zadaniami. Dwie encje domenowe (Project, TaskItem), pięć endpointów, SQLite, Clean Architecture, MediatR. Mały, ale zbudowany porządnie.

Co skonfigurujemy: instrukcje Copilota, skill do testów, agent code reviewer, hook quality gate. Komplet z Cookbooka – tym razem na żywym projekcie.

Czas: około 45 minut przy spokojnym tempie.

Część 1 – Repozytorium i struktura projektu
1
Stwórz repozytorium na GitHubie
⏱ ~3 min

Wejdź na github.com i zaloguj się. Tworzymy nowe, publiczne repozytorium.

github.com → New repository
Kliknij przycisk New w lewym górnym rogu (obok "Top Repositories") lub ikonę + w prawym górnym rogu → New repository

Repository name: taskflow-api
Description: TaskFlow API – demo projektu agentic development z GitHub Copilot
Visibility: ● Public (wymagane dla Coding Agenta w Free tier Actions minutes)

Zaznacz: ☑ Add a README file
Zaznacz: ☑ Add .gitignore → wybierz VisualStudio z listy

Kliknij Create repository
→ GitHub przekieruje Cię do głównej strony nowego repozytorium z jednym commitem "Initial commit"
✅ Efekt
Masz repozytorium github.com/[twój-login]/taskflow-api z plikami README.md i .gitignore.
2
Sklonuj i stwórz projekt .NET
⏱ ~5 min

Klonujemy repo i tworzymy strukturę Clean Architecture. Kopiuj komendy po kolei:

# Sklonuj repozytorium (zamień [twój-login] na swój login GitHub)
git clone https://github.com/[twój-login]/taskflow-api.git
cd taskflow-api

# Stwórz solution i projekty
dotnet new sln -n TaskFlow
dotnet new webapi -n TaskFlow.API --no-openapi -o src/TaskFlow.API
dotnet new classlib -n TaskFlow.Application -o src/TaskFlow.Application
dotnet new classlib -n TaskFlow.Domain -o src/TaskFlow.Domain
dotnet new classlib -n TaskFlow.Infrastructure -o src/TaskFlow.Infrastructure
dotnet new xunit -n TaskFlow.Tests -o tests/TaskFlow.Tests

# Dodaj projekty do solution
dotnet sln add src/TaskFlow.API/TaskFlow.API.csproj
dotnet sln add src/TaskFlow.Application/TaskFlow.Application.csproj
dotnet sln add src/TaskFlow.Domain/TaskFlow.Domain.csproj
dotnet sln add src/TaskFlow.Infrastructure/TaskFlow.Infrastructure.csproj
dotnet sln add tests/TaskFlow.Tests/TaskFlow.Tests.csproj

# Referencje między projektami
dotnet add src/TaskFlow.API reference src/TaskFlow.Application
dotnet add src/TaskFlow.Application reference src/TaskFlow.Domain
dotnet add src/TaskFlow.Infrastructure reference src/TaskFlow.Application
dotnet add tests/TaskFlow.Tests reference src/TaskFlow.Application
dotnet add tests/TaskFlow.Tests reference src/TaskFlow.Domain

# NuGet – pakiety
dotnet add src/TaskFlow.API package MediatR.Extensions.Microsoft.DependencyInjection
dotnet add src/TaskFlow.Application package MediatR
dotnet add src/TaskFlow.Application package FluentValidation.DependencyInjectionExtensions
dotnet add src/TaskFlow.Application package Ardalis.Result
dotnet add src/TaskFlow.Infrastructure package Microsoft.EntityFrameworkCore.Sqlite
dotnet add src/TaskFlow.Infrastructure package Microsoft.EntityFrameworkCore.Design
dotnet add src/TaskFlow.API package Microsoft.EntityFrameworkCore.Design
dotnet add tests/TaskFlow.Tests package FluentAssertions
dotnet add tests/TaskFlow.Tests package NSubstitute

# Sprawdź że solution się buduje
dotnet build TaskFlow.sln
Terminal – oczekiwany wynik
Build succeeded.
    0 Warning(s)
    0 Error(s)
→ Jeśli widzisz błędy NuGet – uruchom dotnet restore i spróbuj ponownie

Otwórz projekt w VS Code:

code .
✅ Efekt
VS Code otwiera się z projektem TaskFlow. W panelu Explorer widzisz foldery src/ i tests/.
3
Konfiguracja Copilota – trzy pliki
⏱ ~8 min

To serce całej konfiguracji. Stwórz te pliki w VS Code – możesz użyć terminala lub File Explorer po lewej.

Plik 1 – Główne instrukcje projektu

Utwórz plik .github/copilot-instructions.md:

# Instrukcje – TaskFlow API

## Stack technologiczny
- .NET 9, C# 13
- ASP.NET Core Minimal API
- Entity Framework Core 9 + SQLite
- MediatR + FluentValidation + Ardalis.Result
- xUnit + FluentAssertions + NSubstitute

## Architektura – Clean Architecture
- `src/TaskFlow.Domain` – encje Project i TaskItem, interfejsy repozytoriów
- `src/TaskFlow.Application` – commandy, query, handlery MediatR, validatory
- `src/TaskFlow.Infrastructure` – EF Core DbContext, repozytoria
- `src/TaskFlow.API` – Minimal API endpoints, rejestracja DI

## Kluczowe konwencje
- Warstwa Application NIGDY nie używa DbContext bezpośrednio
- Każdy endpoint używa ISender (MediatR), nie serwisów bezpośrednio
- Handlery zwracają Ardalis.Result
- Async wszędzie – brak .Result i .Wait()
- CancellationToken jako ostatni parametr każdej metody async

## Nazewnictwo
- Commandy: [Akcja][Encja]Command (CreateProjectCommand)
- Query: Get[Encja]Query, Get[Encja]sQuery
- Handlery: [Nazwa]Handler
- Walidatory: [Nazwa]Validator
- Testy: [Klasa]Tests, metody: [Metoda]_When[Warunek]_Should[Wynik]

## Stack testowy
- xUnit 2, FluentAssertions, NSubstitute
- Wzorzec AAA z komentarzami // Arrange // Act // Assert
- Mockuj NSubstitute: _repo = Substitute.For()
- Testuj zachowanie (wynik), nie implementację (wywołania mocków)

## Czego NIE rób
- Nie dodawaj NuGet bez pytania
- Nie używaj DbContext w warstwie Application
- Nie hardcoduj connection strings
- Nie twórz kontrolerów MVC – tylko Minimal API

Plik 2 – Instrukcja path-specific dla testów

Utwórz plik .github/instructions/tests.instructions.md:

---
description: Standardy testów jednostkowych TaskFlow
applyTo: "**/*Tests.cs, **/Tests/**/*.cs"
---

# Testy jednostkowe – TaskFlow

Używaj xUnit 2, FluentAssertions i NSubstitute. Wzorzec AAA.
Konwencja nazewnictwa: [Metoda]_When[Warunek]_Should[Wynik]

Szablon klasy testowej:
```csharp
public class [Klasa]Tests
{
    private readonly I[Dep] _dep = Substitute.For();
    private readonly [Klasa] _sut;
    public [Klasa]Tests() => _sut = new [Klasa](_dep);
}
```

Plik 3 – Konfiguracja Coding Agenta

Utwórz plik .github/copilot-setup-steps.yml:

steps:
  - name: Setup .NET 9
    uses: actions/setup-dotnet@v4
    with:
      dotnet-version: '9.0.x'

  - name: Restore packages
    run: dotnet restore TaskFlow.sln

  - name: Build
    run: dotnet build TaskFlow.sln --no-restore

  - name: Run tests (baseline)
    run: dotnet test TaskFlow.sln --no-build --verbosity normal
    continue-on-error: true

Plik 4 – Hook quality gate

Utwórz plik .github/hooks/quality-gate.json:

{
  "hooks": [
    {
      "event": "agentStop",
      "command": {
        "windows": "powershell -ExecutionPolicy Bypass -File .github/hooks/quality-gate.ps1",
        "linux":   "bash .github/hooks/quality-gate.sh",
        "mac":     "bash .github/hooks/quality-gate.sh"
      }
    }
  ]
}

Utwórz plik .github/hooks/quality-gate.sh:

#!/usr/bin/env bash
set -euo pipefail
ERRORS=0
echo "🔬 TaskFlow Quality Gate"

echo "▶ [1/2] dotnet format..."
if ! dotnet format TaskFlow.sln --verify-no-changes 2>&1; then
    echo "❌ Błędy formatowania – uruchom: dotnet format TaskFlow.sln"
    ERRORS=$((ERRORS+1))
else echo "✅ Format OK"; fi

echo "▶ [2/2] dotnet build (analyzers)..."
if ! dotnet build TaskFlow.sln --no-restore -p:TreatWarningsAsErrors=true --verbosity quiet 2>&1; then
    echo "❌ Build / analyzery nieudane"
    ERRORS=$((ERRORS+1))
else echo "✅ Build OK"; fi

[ "$ERRORS" -gt 0 ] && { echo "🚫 Quality gate NIEUDANY ($ERRORS problem(y))"; exit 1; }
echo "✅ Quality gate ZALICZONY"

Utwórz plik .github/hooks/quality-gate.ps1 (Windows):

$errors = 0
Write-Host "🔬 TaskFlow Quality Gate"
dotnet format TaskFlow.sln --verify-no-changes
if ($LASTEXITCODE -ne 0) { Write-Host "❌ Format"; $errors++ } else { Write-Host "✅ Format OK" }
dotnet build TaskFlow.sln --no-restore -p:TreatWarningsAsErrors=true --verbosity quiet
if ($LASTEXITCODE -ne 0) { Write-Host "❌ Build"; $errors++ } else { Write-Host "✅ Build OK" }
if ($errors -gt 0) { Write-Host "🚫 NIEUDANY ($errors)"; exit 1 }
Write-Host "✅ ZALICZONY"

Scommituj wszystko:

git add .
git commit -m "Add Copilot configuration: instructions, setup steps, quality gate hook"
git push
✅ Efekt
Repozytorium ma folder .github/ z czterema plikami konfiguracyjnymi. Copilot jest gotowy – zna architekturę, stack testowy i standardy projektu.
Część 2 – Domain i Infrastructure (agent mode)
4
Domain – encje i interfejsy repozytoriów
⏱ ~8 min WSZYSTKIE PLANY

Otwórz Copilot Chat w VS Code – skrót Ctrl+Alt+I lub ikona czatu w lewym panelu. Upewnij się że jesteś w trybie Agent (nie Ask).

VS Code – Copilot Chat panel
W górnej części chatu widzisz dropdown modelu. Obok niego – dropdown trybu: Ask | Agent | Edit

Kliknij Agent – upewnij się że jest wybrany.

Kliknij ikonę + lub New Chat żeby zacząć czystą sesję.
→ Tryb Agent pozwala Copilotowi czytać i tworzyć pliki, uruchamiać komendy i korzystać z narzędzi

Wklej do chatu ten prompt i wyślij:

Stwórz warstwę Domain dla projektu TaskFlow API.

Potrzebuję:

1. Encja Project w pliku src/TaskFlow.Domain/Entities/Project.cs:
   - Id (int), Name (string), Description (string?), CreatedAt (DateTime)
   - Kolekcja TaskItems
   - Konstruktor i metoda Update(name, description)

2. Encja TaskItem w pliku src/TaskFlow.Domain/Entities/TaskItem.cs:
   - Id (int), Title (string), IsCompleted (bool), ProjectId (int)
   - Referencja do Project
   - Konstruktor i metoda Complete()

3. Interfejs IProjectRepository w pliku src/TaskFlow.Domain/Interfaces/IProjectRepository.cs:
   - GetAllAsync, GetByIdAsync, AddAsync, UpdateAsync, DeleteAsync

4. Interfejs ITaskItemRepository w pliku src/TaskFlow.Domain/Interfaces/ITaskItemRepository.cs:
   - GetByProjectIdAsync, GetByIdAsync, AddAsync, UpdateAsync, DeleteAsync

Po stworzeniu plików uruchom dotnet build TaskFlow.sln i upewnij się że build jest zielony.
VS Code – Copilot Agent odpowiada
Copilot zaczyna działać. W panelu chatu widzisz sekwencję kroków:

▸ Creating file: src/TaskFlow.Domain/Entities/Project.cs
▸ Creating file: src/TaskFlow.Domain/Entities/TaskItem.cs
▸ Creating file: src/TaskFlow.Domain/Interfaces/IProjectRepository.cs
▸ Creating file: src/TaskFlow.Domain/Interfaces/ITaskItemRepository.cs
▸ Running: dotnet build TaskFlow.sln

Po chwili widzisz wynik buildu. Jeśli są błędy – agent naprawia je sam.

Po zakończeniu agent wyświetla podsumowanie co stworzył i prosi o potwierdzenie lub feedback.
→ Sprawdź pliki w Explorer – powinny pojawić się w src/TaskFlow.Domain/
⚠️ Agent pokazuje diff przed zapisem

Przy tworzeniu lub modyfikacji plików agent mode w VS Code często pokazuje podgląd zmian z przyciskami Accept / Discard. Przejrzyj szybko i kliknij Accept All jeśli wygląda dobrze. Możesz też kliknąć konkretny plik żeby zobaczyć co się zmienia.

Następnie scommituj:

git add .
git commit -m "Add Domain layer: Project, TaskItem entities and repository interfaces"
git push
5
Infrastructure – DbContext i repozytoria (agent mode)
⏱ ~6 min WSZYSTKIE PLANY

Kontynuuj w tym samym oknie chatu (agent zachowuje kontekst sesji). Wklej:

Stwórz warstwę Infrastructure dla TaskFlow API.

1. TaskFlowDbContext w src/TaskFlow.Infrastructure/Data/TaskFlowDbContext.cs:
   - Dziedziczy po DbContext
   - DbSet Projects i DbSet TaskItems
   - OnModelCreating: skonfiguruj relację 1-do-wielu Project→TaskItems

2. ProjectRepository w src/TaskFlow.Infrastructure/Repositories/ProjectRepository.cs:
   - Implementuje IProjectRepository
   - Konstruktor przyjmuje TaskFlowDbContext
   - Implementuj wszystkie metody interfejsu używając EF Core async

3. TaskItemRepository w src/TaskFlow.Infrastructure/Repositories/TaskItemRepository.cs:
   - Implementuje ITaskItemRepository
   - Analogicznie do ProjectRepository

4. Rozszerzenie DI w src/TaskFlow.Infrastructure/DependencyInjection.cs:
   - Metoda statyczna AddInfrastructure(this IServiceCollection services, IConfiguration config)
   - Rejestracja DbContext z SQLite (connection string: "Data Source=taskflow.db")
   - Rejestracja repozytoriów

Po stworzeniu plików: dotnet build TaskFlow.sln
✅ Efekt
Infrastructure layer gotowa. Commit i push po akceptacji zmian:
git add . && git commit -m "Add Infrastructure layer: DbContext, repositories, DI" && git push
Część 3 – Pierwsze issue: zarządzanie projektami
6
Stwórz issue i deleguj do agenta
⏱ ~5 min

Teraz rozwidlamy się na dwie ścieżki. Wybierz swoją:

FREE Agent mode w VS Code

Kontynuuj sesję agenta w VS Code. Wklej prompt bezpośrednio do chatu:

Zaimplementuj zarządzanie projektami w TaskFlow API.

Potrzebuję w warstwie Application (src/TaskFlow.Application/Projects/):

1. GetProjectsQuery + GetProjectsQueryHandler
   - Zwraca Result> gdzie ProjectDto: { Id, Name, Description, CreatedAt, TaskCount }

2. GetProjectByIdQuery + GetProjectByIdQueryHandler
   - Zwraca Result
   - Jeśli nie istnieje: Result.NotFound()

3. CreateProjectCommand + CreateProjectCommandHandler
   - Parametry: Name (string), Description (string?)
   - Tworzy projekt i zapisuje przez IProjectRepository
   - Zwraca Result (Id nowego projektu)

4. CreateProjectCommandValidator (FluentValidation)
   - Name: NotEmpty, MaxLength(100)
   - Description: MaxLength(500)

5. Endpoints w src/TaskFlow.API/Endpoints/ProjectsEndpoints.cs:
   - GET /api/projects
   - GET /api/projects/{id}
   - POST /api/projects

6. Rejestracja DI Application w src/TaskFlow.Application/DependencyInjection.cs

7. Aktualizacja Program.cs: AddApplication(), AddInfrastructure(), MapProjectsEndpoints()

8. Testy jednostkowe dla CreateProjectCommandHandler w tests/TaskFlow.Tests/

Po implementacji: dotnet build TaskFlow.sln && dotnet test TaskFlow.sln
VS Code – agent pracuje (~3-5 minut)
Obserwujesz strumień akcji w panelu chatu:

▸ Reading: src/TaskFlow.Domain/Interfaces/IProjectRepository.cs
▸ Creating: src/TaskFlow.Application/Projects/GetProjectsQuery.cs
▸ Creating: src/TaskFlow.Application/Projects/CreateProjectCommand.cs
▸ Creating: src/TaskFlow.API/Endpoints/ProjectsEndpoints.cs
▸ Creating: tests/TaskFlow.Tests/CreateProjectCommandHandlerTests.cs
▸ Running: dotnet build TaskFlow.sln
▸ Running: dotnet test TaskFlow.sln

Build succeeded. Tests passed (3/3).
→ Kliknij Accept All zmiany, przejrzyj wygenerowane pliki
PRO / STUDENT Coding Agent na GitHub.com

Wróć do github.com/[twój-login]/taskflow-api. Stwórz issue:

github.com/[login]/taskflow-api → Issues → New issue
Kliknij zakładkę IssuesNew issue

Title: Implement project management endpoints

Description – wklej tekst poniżej:

[tu wklej ten sam prompt co w ścieżce FREE – pełen tekst]

Kliknij Submit new issue
Otwarte issue – przypisanie do Copilota
Po stworzeniu issue widzisz jego stronę. W prawym panelu szukasz sekcji Assignees.

Kliknij koło zębate ⚙️ obok Assignees

W polu wyszukiwania zacznij pisać: Cop – pojawi się opcja:

    ● Copilot  (GitHub Copilot)

Kliknij Copilot → kliknij poza dropdown żeby zamknąć

Pojawia się dialog "Start a session for Copilot?" z polem Optional prompt.

W Optional prompt wpisz:
Zacznij od przeczytania .github/copilot-instructions.md. Użyj Ardalis.Result dla wszystkich handlerów.

Kliknij Start session
→ W issue pojawia się wpis "Copilot is working on this" z linkiem do sesji w Actions
github.com → Actions – obserwuj sesję agenta
Kliknij zakładkę Actions w repo. Widzisz nowy run: "Copilot Session" ze spinnerem.

Kliknij na ten run → widzisz log sesji w czasie rzeczywistym:

Reading .github/copilot-instructions.md...
Analyzing repository structure...
Creating src/TaskFlow.Application/Projects/GetProjectsQuery.cs
Creating src/TaskFlow.Application/Projects/CreateProjectCommand.cs
Running: dotnet build TaskFlow.sln
Build succeeded.
Running quality gate hook...
✅ Quality gate ZALICZONY

Sesja trwa ~10-15 minut. Możesz zamknąć zakładkę – dostaniesz notyfikację gdy skończy.
→ Po zakończeniu w issue pojawia się link do draft PR
7
Review i merge pierwszego PR
⏱ ~8 min PRO: review na GitHub FREE: lokalnie
FREE Commit i weryfikacja lokalna

Po akceptacji zmian od agenta, zrób szybki review i commit:

# Sprawdź co się zmieniło
git diff --stat

# Uruchom testy
dotnet test TaskFlow.sln --verbosity normal

# Jeśli wszystko gra – commit
git add .
git commit -m "Implement project management: CQRS handlers, endpoints, tests"
git push
PRO / STUDENT Review draft PR na GitHub
github.com – Pull Requests → draft PR od Copilota
Kliknij zakładkę Pull requests → widzisz PR z etykietą Draft stworzony przez Copilota.

Tytuł będzie nawiązywać do issue, np. "Implement project management endpoints"

Kliknij Files changed → przejrzyj diff:

    ☐ Czy są tylko pliki z zakresu zadania?
    ☐ Czy Application nie dotyka DbContext?
    ☐ Czy endpoint używa ISender?
    ☐ Czy testy testują zachowanie?

Jeśli coś wymaga poprawki – dodaj komentarz w kodzie z @copilot:

@copilot W CreateProjectCommandHandler brakuje logowania. Dodaj ILogger i zaloguj sukces przez _logger.LogInformation.

→ Copilot odpowie w ciągu ~2-3 minut, zaktualizuje PR
Gdy PR jest gotowy do merge: kliknij "Ready for review" → poproś kolegę o final review lub (jeśli repo jest Twoje solo) zmień branch protection rules
✅ Efekt po Kroku 7
Masz działające endpointy GET /api/projects, GET /api/projects/{"{id}"} i POST /api/projects z testami jednostkowymi. Clean Architecture, MediatR, Ardalis.Result – wszystko zgodne z instrukcjami Copilota.
Część 4 – Drugie issue: zarządzanie zadaniami
8
Issue #2 – CRUD zadań i oznaczanie jako ukończone
⏱ ~10 min

Ten krok powtarza flow z Kroku 6 – ale tym razem widzisz że delegowanie idzie płynniej bo agent zna już wzorce z poprzedniego issue. Użyj wybranej ścieżki (FREE: agent mode w VS Code / PRO: nowe issue na GitHub).

Prompt do wklejenia:

Zaimplementuj zarządzanie zadaniami (TaskItems) w TaskFlow API.
Wzoruj się na implementacji Projects z poprzedniego issue.

W warstwie Application (src/TaskFlow.Application/Tasks/):

1. GetTasksByProjectQuery + Handler
   - Zwraca Result> gdzie TaskItemDto: { Id, Title, IsCompleted, ProjectId }
   - Jeśli projekt nie istnieje: Result.NotFound()

2. CreateTaskCommand + Handler + Validator
   - Parametry: ProjectId (int), Title (string)
   - Title: NotEmpty, MaxLength(200)
   - Zwraca Result (Id nowego zadania)
   - Zwróć NotFound jeśli projekt ProjectId nie istnieje

3. CompleteTaskCommand + Handler
   - Parametry: TaskId (int)
   - Wywołuje task.Complete() na encji domenowej
   - Zwraca Result.Success() lub Result.NotFound()

4. Endpoints w src/TaskFlow.API/Endpoints/TasksEndpoints.cs:
   - GET /api/projects/{projectId}/tasks
   - POST /api/projects/{projectId}/tasks
   - PUT /api/tasks/{id}/complete

5. Zarejestruj endpointy w Program.cs

6. Testy jednostkowe dla CreateTaskCommandHandler i CompleteTaskCommandHandler

Po implementacji: dotnet build TaskFlow.sln && dotnet test TaskFlow.sln
🔍 Obserwuj jak agent korzysta z kontekstu

Przy drugim issue zwróć uwagę na jedną rzecz: agent szuka wzorców w istniejącym kodzie zanim coś napisze. Widać to w logach – odczytuje CreateProjectCommandHandler.cs jako przykład zanim napisze CreateTaskCommandHandler.cs. To jest właśnie "example-driven generation" – dlaczego wskazywanie wzorców w issue (z wpisu 11) daje lepsze wyniki niż długie opisy.

Po zakończeniu – commit lub merge PR analogicznie do Kroku 7.

✅ Efekt po Kroku 8
Kompletne API: pięć endpointów, dwie encje domenowe, sześć handlerów MediatR, testy. Cały projekt buduje się bez błędów i warningów.
Część 5 – Uruchomienie i weryfikacja końcowa
9
Uruchom API i przetestuj endpointy
⏱ ~5 min WSZYSTKIE PLANY

Czas uruchomić to co zbudowaliśmy:

# Uruchom API
cd src/TaskFlow.API
dotnet run
Terminal – TaskFlow API uruchomione
info: Microsoft.Hosting.Lifetime[14]
    Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
    Application started.
→ API nasłuchuje na porcie 5000 (lub innym – sprawdź w logu)

W nowym oknie terminala przetestuj endpointy przez curl lub Thunder Client (rozszerzenie VS Code):

# Stwórz projekt
curl -X POST http://localhost:5000/api/projects \
  -H "Content-Type: application/json" \
  -d '{"name": "Mój pierwszy projekt", "description": "Test TaskFlow API"}'

# Pobierz projekty
curl http://localhost:5000/api/projects

# Stwórz zadanie (użyj ID zwróconego powyżej, np. 1)
curl -X POST http://localhost:5000/api/projects/1/tasks \
  -H "Content-Type: application/json" \
  -d '{"title": "Pierwsze zadanie", "projectId": 1}'

# Pobierz zadania projektu
curl http://localhost:5000/api/projects/1/tasks

# Oznacz zadanie jako ukończone (użyj ID zadania, np. 1)
curl -X PUT http://localhost:5000/api/tasks/1/complete
Terminal – oczekiwane odpowiedzi
POST /api/projects → HTTP 201  {"value": 1, "status": 1}
GET /api/projects → HTTP 200  [{"id":1,"name":"Mój pierwszy projekt",...}]
POST /api/projects/1/tasks → HTTP 201  {"value": 1}
PUT /api/tasks/1/complete → HTTP 200
→ Jeśli widzisz błędy 500 – sprawdź czy baza SQLite została stworzona przez EF (powinno być taskflow.db w katalogu src/TaskFlow.API)

Ostatni commit:

cd ../..
git add .
git commit -m "TaskFlow API complete: projects + tasks CRUD, Clean Architecture, tests"
git push
Co właśnie zrobiłeś – i dlaczego to ważne

W ciągu 45 minut zbudowałeś działające API z Clean Architecture, MediatR, FluentValidation, testami jednostkowymi i kompletną konfiguracją agentic development. Nie napisałeś tego sam – ale też nie puściłeś agenta bez nadzoru. Zrobiłeś coś ważniejszego: nauczyłeś się jak skutecznie delegować.

🌟 Co zadziałało i dlaczego
  • Instrukcje Copilota sprawiły że agent wiedział o Ardalis.Result, ISender i konwencjach nazewnictwa zanim go o cokolwiek poprosiłeś. Bez nich – musiałbyś poprawiać architekturę w każdym PR.
  • copilot-setup-steps.yml dał Coding Agentowi gotowe środowisko. Agent nie tracił czasu na "dlaczego build nie działa" – od razu wiedział co jest zielone, a co czerwone.
  • Hook quality gate wyłapał błędy formatowania i warningi zanim zobaczyłeś PR. Agent naprawił je sam w tej samej sesji.
  • Konkretny prompt z issue – lista plików, konwencje, polecenie uruchomienia testów – dała agentowi jasno zdefiniowane "done". Bez tego agent kończy gdy mu się wydaje że skończył.
  • Drugie issue poszło szybciej niż pierwsze. Agent zapamiętał wzorce z Projects i zastosował je do Tasks bez dodatkowych instrukcji. To jest skalowanie przez przykład.

Co możesz zrobić dalej z TaskFlow API

  • Dodaj autoryzację JWT – jedno issue: "Add JWT authentication to all endpoints except health check"
  • Dodaj paginację do GET /api/projects – klasyczne, bezpieczne zadanie dla Coding Agenta
  • Dodaj MCP PostgreSQL i zmień SQLite na prawdziwą bazę danych
  • Dodaj agentic workflow triage issues – skopiuj z Wpisu 10 i dostosuj do taskflow-api
  • Zapakuj konfigurację w plugin i zainstaluj w nowym projekcie jedną komendą
💪 Wyzwanie końcowe – DeleteProject

Napisz sam (bez podpowiadania agentowi gotowego rozwiązania) issue które deleguje implementację DELETE /api/projects/{"{id}"}. Wymaganie: kaskadowe usunięcie zadań projektu, NotFound jeśli projekt nie istnieje, test jednostkowy handlera.

To jest teraz Twoja naturalna praca – pisanie dobrze opisanych wymagań. Agent to tylko wdraża.

Doceniasz moją pracę? Wesprzyj bloga 'kupując mi kawę'.

Jeżeli seria wpisów dotycząca Agentic Development była dla Ciebie pomocna, pozwoliła Ci rozwinąć obecne umiejętności lub dzięki niej nauczyłeś się czegoś nowego... będę wdzięczny za wsparcie w każdej postaci wraz z wiadomością, którą będę miał przyjemność przeczytać.

Z góry dziekuje za każde wsparcie - i pamiętajcie, wpisy były, są i będą za darmo!


Koniec cyklu „Agentic Development z GitHub Copilot" · 15 wpisów + 1 bonus