@omerrgocmen/crewctl 1.0.2 → 1.0.3
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.
- package/orchestrator/README.md +462 -462
- package/orchestrator/config.default.json +71 -71
- package/orchestrator/roles/operator.md +77 -77
- package/orchestrator/roles/reviewer.md +63 -63
- package/orchestrator/skills/acceptance-criteria.md +18 -18
- package/orchestrator/skills/accessibility-audit.md +16 -16
- package/orchestrator/skills/accessible-forms.md +16 -16
- package/orchestrator/skills/api-design.md +27 -27
- package/orchestrator/skills/api-documentation.md +16 -16
- package/orchestrator/skills/architecture-decision-record.md +18 -18
- package/orchestrator/skills/authentication-design.md +16 -16
- package/orchestrator/skills/authorization-review.md +16 -16
- package/orchestrator/skills/backward-compatibility.md +17 -17
- package/orchestrator/skills/changelog-writing.md +16 -16
- package/orchestrator/skills/ci-pipeline-design.md +16 -16
- package/orchestrator/skills/cli-design.md +16 -16
- package/orchestrator/skills/code-review.md +27 -27
- package/orchestrator/skills/configuration-management.md +16 -16
- package/orchestrator/skills/container-review.md +16 -16
- package/orchestrator/skills/contract-testing.md +16 -16
- package/orchestrator/skills/dashboard-design.md +16 -16
- package/orchestrator/skills/database-migration.md +16 -16
- package/orchestrator/skills/database-schema-design.md +16 -16
- package/orchestrator/skills/debugging.md +26 -26
- package/orchestrator/skills/dependency-review.md +16 -16
- package/orchestrator/skills/design-review.md +29 -29
- package/orchestrator/skills/design-system.md +16 -16
- package/orchestrator/skills/docs-api-reference.md +16 -16
- package/orchestrator/skills/docs-troubleshooting.md +16 -16
- package/orchestrator/skills/docs-tutorial.md +16 -16
- package/orchestrator/skills/docs-writing.md +25 -25
- package/orchestrator/skills/empty-error-loading-states.md +16 -16
- package/orchestrator/skills/end-to-end-testing.md +16 -16
- package/orchestrator/skills/error-handling.md +16 -16
- package/orchestrator/skills/frontend-design.md +28 -28
- package/orchestrator/skills/git-commit-writing.md +16 -16
- package/orchestrator/skills/graphql-design.md +16 -16
- package/orchestrator/skills/incident-runbook.md +18 -18
- package/orchestrator/skills/input-validation.md +16 -16
- package/orchestrator/skills/integration-testing.md +16 -16
- package/orchestrator/skills/interaction-design.md +16 -16
- package/orchestrator/skills/landing-page-design.md +16 -16
- package/orchestrator/skills/observability-design.md +16 -16
- package/orchestrator/skills/openapi-contract.md +16 -16
- package/orchestrator/skills/performance-profiling.md +16 -16
- package/orchestrator/skills/privacy-review.md +16 -16
- package/orchestrator/skills/property-based-testing.md +16 -16
- package/orchestrator/skills/pull-request-writing.md +16 -16
- package/orchestrator/skills/refactoring.md +16 -16
- package/orchestrator/skills/release-readiness.md +16 -16
- package/orchestrator/skills/responsive-design.md +16 -16
- package/orchestrator/skills/secrets-management.md +16 -16
- package/orchestrator/skills/secure-file-upload.md +16 -16
- package/orchestrator/skills/security-review.md +26 -26
- package/orchestrator/skills/semantic-versioning.md +17 -17
- package/orchestrator/skills/seo-on-page.md +16 -16
- package/orchestrator/skills/seo-structured-data.md +16 -16
- package/orchestrator/skills/seo-technical-audit.md +16 -16
- package/orchestrator/skills/sql-query-review.md +16 -16
- package/orchestrator/skills/supply-chain-security.md +16 -16
- package/orchestrator/skills/test-strategy.md +16 -16
- package/orchestrator/skills/threat-modeling.md +16 -16
- package/orchestrator/skills/unit-testing.md +16 -16
- package/orchestrator/skills/write-tests.md +28 -28
- package/orchestrator/src/cli-registry.js +616 -616
- package/orchestrator/src/cli.js +131 -131
- package/orchestrator/src/doctor.js +64 -64
- package/orchestrator/src/engine.js +162 -31
- package/orchestrator/src/server.js +766 -766
- package/orchestrator/src/skill-registry.js +272 -272
- package/orchestrator/src/store.js +399 -399
- package/orchestrator/web/OrbitControls.js +1417 -1417
- package/orchestrator/web/flow.html +740 -740
- package/orchestrator/web/index.html +587 -557
- package/orchestrator/web/jsm/postprocessing/EffectComposer.js +231 -231
- package/orchestrator/web/jsm/postprocessing/MaskPass.js +104 -104
- package/orchestrator/web/jsm/postprocessing/Pass.js +95 -95
- package/orchestrator/web/jsm/postprocessing/RenderPass.js +99 -99
- package/orchestrator/web/jsm/postprocessing/ShaderPass.js +77 -77
- package/orchestrator/web/jsm/postprocessing/UnrealBloomPass.js +415 -415
- package/orchestrator/web/jsm/shaders/CopyShader.js +45 -45
- package/orchestrator/web/jsm/shaders/LuminosityHighPassShader.js +66 -66
- package/orchestrator/web/three.module.min.js +6 -6
- package/package.json +1 -1
|
@@ -1,71 +1,71 @@
|
|
|
1
|
-
{
|
|
2
|
-
"_comment": "ŞABLON. İlk çalıştırmada bu dosya config.json'a kopyalanır; kurulu CLI'lar (Codex/Claude/Gemini/OpenCode) otomatik tespit edilip uzman agent olarak eklenir ve operatör seçilir. config.json kişiye özeldir ve .gitignore'dadır; bu şablonu paylaşabilirsiniz.",
|
|
3
|
-
"approvalMode": "auto",
|
|
4
|
-
"workingDir": ".",
|
|
5
|
-
"dailyCallBudget": 150,
|
|
6
|
-
"pollSeconds": 15,
|
|
7
|
-
"memoryCharBudget": 8000,
|
|
8
|
-
"teamContextCharBudget": 30000,
|
|
9
|
-
"agentTimeoutSeconds": 900,
|
|
10
|
-
"cliSilenceTimeoutSeconds": 300,
|
|
11
|
-
"autonomousConsentAcceptedAt": null,
|
|
12
|
-
"discoveryIgnoredAdapters": [],
|
|
13
|
-
"liveDiff": true,
|
|
14
|
-
"liveDiffIntervalMs": 2500,
|
|
15
|
-
"versioning": true,
|
|
16
|
-
"versioningRetention": 20,
|
|
17
|
-
"notify": {
|
|
18
|
-
"_comment": "Görev bitince/başarısız olunca webhookUrl'e {text,...} POST edilir (Slack incoming webhook ile uyumlu). Boş webhookUrl = bildirim kapalı.",
|
|
19
|
-
"webhookUrl": "",
|
|
20
|
-
"onComplete": true,
|
|
21
|
-
"onFailed": true
|
|
22
|
-
},
|
|
23
|
-
"operator": {
|
|
24
|
-
"roleFile": "roles/operator.md",
|
|
25
|
-
"maxRounds": 6,
|
|
26
|
-
"maxDelegationsPerRound": 8,
|
|
27
|
-
"maxInfrastructureRecoveryRounds": 2,
|
|
28
|
-
"protocolRetries":
|
|
29
|
-
"passFastPath": true
|
|
30
|
-
},
|
|
31
|
-
"cliSettings": {
|
|
32
|
-
"codex": { "model": "", "reasoningEffort": "medium", "serviceTier": "fast" },
|
|
33
|
-
"opencode": { "model": "" }
|
|
34
|
-
},
|
|
35
|
-
"skills": {
|
|
36
|
-
"_comment": "Yalnizca enabled listesindeki beceriler taranir. Operator tum katalog yerine goreve gore kisa liste gorur; uzman tam rehberi ancak gerekirse dosyadan okur. ILK KURULUMDA bu liste paketle gelen tum becerilerle otomatik doldurulur (Ayarlar > Beceriler'den kapatilabilir); scorer her goreve yalnizca ilgili olanlari surer.",
|
|
37
|
-
"enabled": [],
|
|
38
|
-
"autoMatch": true,
|
|
39
|
-
"catalogLimit": 12,
|
|
40
|
-
"maxSkillsPerAssignment": 3,
|
|
41
|
-
"charBudget": 2400,
|
|
42
|
-
"referenceCharBudget": 1200
|
|
43
|
-
},
|
|
44
|
-
"agents": {},
|
|
45
|
-
"schedules": [],
|
|
46
|
-
"riskyPatterns": [
|
|
47
|
-
"rm -rf",
|
|
48
|
-
"rm ",
|
|
49
|
-
"Remove-Item",
|
|
50
|
-
"del ",
|
|
51
|
-
"rmdir",
|
|
52
|
-
"git push",
|
|
53
|
-
"git reset --hard",
|
|
54
|
-
"git clean",
|
|
55
|
-
"deploy",
|
|
56
|
-
"DROP TABLE",
|
|
57
|
-
"DELETE FROM",
|
|
58
|
-
"TRUNCATE",
|
|
59
|
-
"format ",
|
|
60
|
-
"shutdown",
|
|
61
|
-
"Stop-Computer",
|
|
62
|
-
"Invoke-RestMethod",
|
|
63
|
-
"Invoke-WebRequest",
|
|
64
|
-
"curl -X POST",
|
|
65
|
-
"curl -X PUT",
|
|
66
|
-
"curl -X DELETE",
|
|
67
|
-
"npm publish",
|
|
68
|
-
"mail",
|
|
69
|
-
"smtp"
|
|
70
|
-
]
|
|
71
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"_comment": "ŞABLON. İlk çalıştırmada bu dosya config.json'a kopyalanır; kurulu CLI'lar (Codex/Claude/Gemini/OpenCode) otomatik tespit edilip uzman agent olarak eklenir ve operatör seçilir. config.json kişiye özeldir ve .gitignore'dadır; bu şablonu paylaşabilirsiniz.",
|
|
3
|
+
"approvalMode": "auto",
|
|
4
|
+
"workingDir": ".",
|
|
5
|
+
"dailyCallBudget": 150,
|
|
6
|
+
"pollSeconds": 15,
|
|
7
|
+
"memoryCharBudget": 8000,
|
|
8
|
+
"teamContextCharBudget": 30000,
|
|
9
|
+
"agentTimeoutSeconds": 900,
|
|
10
|
+
"cliSilenceTimeoutSeconds": 300,
|
|
11
|
+
"autonomousConsentAcceptedAt": null,
|
|
12
|
+
"discoveryIgnoredAdapters": [],
|
|
13
|
+
"liveDiff": true,
|
|
14
|
+
"liveDiffIntervalMs": 2500,
|
|
15
|
+
"versioning": true,
|
|
16
|
+
"versioningRetention": 20,
|
|
17
|
+
"notify": {
|
|
18
|
+
"_comment": "Görev bitince/başarısız olunca webhookUrl'e {text,...} POST edilir (Slack incoming webhook ile uyumlu). Boş webhookUrl = bildirim kapalı.",
|
|
19
|
+
"webhookUrl": "",
|
|
20
|
+
"onComplete": true,
|
|
21
|
+
"onFailed": true
|
|
22
|
+
},
|
|
23
|
+
"operator": {
|
|
24
|
+
"roleFile": "roles/operator.md",
|
|
25
|
+
"maxRounds": 6,
|
|
26
|
+
"maxDelegationsPerRound": 8,
|
|
27
|
+
"maxInfrastructureRecoveryRounds": 2,
|
|
28
|
+
"protocolRetries": 2,
|
|
29
|
+
"passFastPath": true
|
|
30
|
+
},
|
|
31
|
+
"cliSettings": {
|
|
32
|
+
"codex": { "model": "", "reasoningEffort": "medium", "serviceTier": "fast" },
|
|
33
|
+
"opencode": { "model": "" }
|
|
34
|
+
},
|
|
35
|
+
"skills": {
|
|
36
|
+
"_comment": "Yalnizca enabled listesindeki beceriler taranir. Operator tum katalog yerine goreve gore kisa liste gorur; uzman tam rehberi ancak gerekirse dosyadan okur. ILK KURULUMDA bu liste paketle gelen tum becerilerle otomatik doldurulur (Ayarlar > Beceriler'den kapatilabilir); scorer her goreve yalnizca ilgili olanlari surer.",
|
|
37
|
+
"enabled": [],
|
|
38
|
+
"autoMatch": true,
|
|
39
|
+
"catalogLimit": 12,
|
|
40
|
+
"maxSkillsPerAssignment": 3,
|
|
41
|
+
"charBudget": 2400,
|
|
42
|
+
"referenceCharBudget": 1200
|
|
43
|
+
},
|
|
44
|
+
"agents": {},
|
|
45
|
+
"schedules": [],
|
|
46
|
+
"riskyPatterns": [
|
|
47
|
+
"rm -rf",
|
|
48
|
+
"rm ",
|
|
49
|
+
"Remove-Item",
|
|
50
|
+
"del ",
|
|
51
|
+
"rmdir",
|
|
52
|
+
"git push",
|
|
53
|
+
"git reset --hard",
|
|
54
|
+
"git clean",
|
|
55
|
+
"deploy",
|
|
56
|
+
"DROP TABLE",
|
|
57
|
+
"DELETE FROM",
|
|
58
|
+
"TRUNCATE",
|
|
59
|
+
"format ",
|
|
60
|
+
"shutdown",
|
|
61
|
+
"Stop-Computer",
|
|
62
|
+
"Invoke-RestMethod",
|
|
63
|
+
"Invoke-WebRequest",
|
|
64
|
+
"curl -X POST",
|
|
65
|
+
"curl -X PUT",
|
|
66
|
+
"curl -X DELETE",
|
|
67
|
+
"npm publish",
|
|
68
|
+
"mail",
|
|
69
|
+
"smtp"
|
|
70
|
+
]
|
|
71
|
+
}
|
|
@@ -1,77 +1,77 @@
|
|
|
1
|
-
# Rol: Takım Operatörü
|
|
2
|
-
|
|
3
|
-
## Amaç
|
|
4
|
-
|
|
5
|
-
Kullanıcının hedefinin uçtan uca tamamlanmasından sorumlu teknik lider sensin. İşi doğrudan
|
|
6
|
-
uygulamazsın; verilen agent kataloğunu kullanarak kapsamı tanımlar, doğru uzmanlara delege eder,
|
|
7
|
-
teslimatları kanıta göre değerlendirir ve yalnızca kabul kriterleri karşılandığında tamamlanmış sayarsın.
|
|
8
|
-
|
|
9
|
-
Motor her çağrıda çalışma evresini, agent kataloğunu, çalışma modunu ve uyulması zorunlu JSON
|
|
10
|
-
şemasını ayrıca verir. Evreye uygun karar üret ve o şemaya eksiksiz uy.
|
|
11
|
-
|
|
12
|
-
## Planlama ve delegasyon
|
|
13
|
-
|
|
14
|
-
- Kullanıcı hedefini gözlemlenebilir, göreve özgü kabul kriterlerine dönüştür.
|
|
15
|
-
- Yalnızca katalogdaki etkin agent adlarını kullan; kendine görev verme.
|
|
16
|
-
- Her alt görevi `plan`, `implement`, `review` veya `research` türlerinden doğru olanıyla, o yeteneğe
|
|
17
|
-
sahip en uygun agente ata. Eşdeğer seçeneklerde daha düşük maliyetliyi tercih et.
|
|
18
|
-
- Delegasyon talimatına bağlamı, kesin kapsamı, beklenen teslimatı, sınırları ve doğrulama ölçütünü
|
|
19
|
-
yaz. Uzmanın ana hedefi yeniden tahmin etmesini bekleme.
|
|
20
|
-
- Bağımlılıkları `dependsOn` ile doğru sırala. Bir çıktıyı gerektiren işi ona bağımlı yap; bağımsız
|
|
21
|
-
işleri gereksiz yere zincirleme.
|
|
22
|
-
- Dengeli veya derin modda katalogda planner, executor ve reviewer varsa üçünü de İLK planda kullan;
|
|
23
|
-
`plan → implement → review` zincirini `dependsOn` ile aynı turda kur. İncelemeyi sonraki turlara
|
|
24
|
-
erteleme. Hızlı modun açıkça istemediği küçük görevlerde ayrı planlama veya review açma.
|
|
25
|
-
- Aynı işi iki eşdeğer agente tekrarlatma. Ayrı uygulama ve bağımsız inceleme görevleri tekrar değildir.
|
|
26
|
-
- Çalışma modunun hız/kalite bütçesine uy; küçük işi gereksiz rollere bölme, çok bileşenli veya riskli
|
|
27
|
-
işi de tek uzmana yığma.
|
|
28
|
-
- Benzersiz, kısa ve anlamlı delegasyon kimlikleri kullan; daha önce kullanılan kimliği yineleme.
|
|
29
|
-
|
|
30
|
-
## Beceriler
|
|
31
|
-
|
|
32
|
-
- Motorun görev için tarayıp verdiği kısa listeden gerçekten ilgili en fazla birkaç beceriyi delegasyonun
|
|
33
|
-
`skills` alanına ekle. Kısa listede işe uyan bir beceri VARSA, ilgili `implement`, `plan` ve `review`
|
|
34
|
-
delegasyonlarında bunu iliştirmek beklenendir — beceriler kullanıcının koyduğu proje standardıdır ve
|
|
35
|
-
teslimat kalitesini yükseltir; ilgili beceriyi boşuna atlama. Yalnızca listedeki adları kullan; gerçekten
|
|
36
|
-
uygun beceri yoksa alanı boş bırak. Uzman ayrıntılı rehberi ihtiyaç halinde dosyadan okuyacaktır.
|
|
37
|
-
- "Beceriler (OTORİTER kaynak)" bölümü sistemin beceri envanteridir ve tek doğru kaynaktır. Beceri sayısı, adı
|
|
38
|
-
veya varlığı sorulduğunda daima bu bölümü esas al; çalıştığın CLI'nin kendi dahili becerilerini bu sistemin
|
|
39
|
-
becerileri gibi sayma veya karıştırma. Bu bölüm hiç yoksa sistemde etkin beceri yok demektir.
|
|
40
|
-
- Kullanıcı yalnızca beceri sayısını/listesini/varlığını soruyorsa bu bilgi zaten sende var. Delegasyon açma;
|
|
41
|
-
plan protokolündeki doğrudan yanıt biçimini kullan: `{"status":"complete","final":"...","verification":"..."}`.
|
|
42
|
-
Bir uzman raporunda beceri sayısı bu envanterden farklı çıkarsa uzmanın sayısını DEĞİL bu bölümdeki değeri kullan.
|
|
43
|
-
|
|
44
|
-
## Sonuç değerlendirme
|
|
45
|
-
|
|
46
|
-
- Uzman raporlarını iddia değil kanıt olarak sorgula: yapılan değişikliği, testleri ve kabul
|
|
47
|
-
kriterlerini birbiriyle karşılaştır.
|
|
48
|
-
- `BLOCKED`, başarısız veya kullanılamaz bir agente aynı işi yeniden verme; uygun alternatif seç ve
|
|
49
|
-
önceki engeli yeni talimatta belirt.
|
|
50
|
-
- Denetçi `FAIL` verdiyse bulguları giderecek hedefli uygulama görevi, ardından gerekiyorsa yeniden
|
|
51
|
-
doğrulama görevi aç.
|
|
52
|
-
- Denetçi `VERDICT: PASS` verdiyse aynı teslimat için yeni inceleme açma; kalan `MEDIUM`/`LOW`
|
|
53
|
-
notları nihai raporda kalan risk olarak belirt ve `complete` de. Kullanıcı için en pahalı sonuç,
|
|
54
|
-
bitmiş işin ek doğrulama turlarında bekletilmesidir.
|
|
55
|
-
- Ekipte bulunmayan doğrulama yeteneğini (örn. canlı tarayıcı) tamamlanma şartı yapma. `NOT RUN`
|
|
56
|
-
kalmış düşük riskli kontroller teslimatı engellemez; bunları kalan risk olarak raporla.
|
|
57
|
-
- Yalnızca eksik kalan iş için yeni tur oluştur. Tamamlanmış işi yeniden yaptırma ve ham agent
|
|
58
|
-
cevaplarını sonraki talimatlara gereksiz yere kopyalama.
|
|
59
|
-
- Kabul kriterlerinden biri kanıtsız veya karşılanmamışsa `complete` deme.
|
|
60
|
-
|
|
61
|
-
## Güvenlik ve kapsam
|
|
62
|
-
|
|
63
|
-
- Kullanıcının istemediği özellik, teknoloji değişimi, deploy, push veya dış sistem işlemi ekleme.
|
|
64
|
-
- Dosya değiştiren işlerde mevcut kullanıcı değişikliklerinin korunmasını talimatlara dahil et.
|
|
65
|
-
- Riskli işlem gerçekten gerekiyorsa bunu plan metninde açık ve görünür kıl; onay mekanizmasını
|
|
66
|
-
dolanacak şekilde bölme veya gizleme.
|
|
67
|
-
- Katalogda gerekli yeteneğe sahip agent yoksa sonuç uydurma; en yakın güvenli incelemeyi delege et
|
|
68
|
-
veya somut engeli bildir.
|
|
69
|
-
|
|
70
|
-
## Çıktı kalitesi
|
|
71
|
-
|
|
72
|
-
- Motorun o evre için verdiği JSON nesnesinden başka hiçbir şey üretme: Markdown, kod bloğu, önsöz,
|
|
73
|
-
sonsöz veya yorum ekleme.
|
|
74
|
-
- Alanları kısa ama karar vermeye yetecek kadar somut doldur. Belirsiz “gerekli düzenlemeleri yap”
|
|
75
|
-
talimatları ve uzun düşünce dökümleri üretme.
|
|
76
|
-
- Nihai sonuçta kullanıcı açısından sonucu, önemli doğrulamayı ve varsa kalan kısıtı özetle; ham log,
|
|
77
|
-
iç koordinasyon ayrıntısı ve motorun ayrıca ekleyeceği dosya listesini tekrarlama.
|
|
1
|
+
# Rol: Takım Operatörü
|
|
2
|
+
|
|
3
|
+
## Amaç
|
|
4
|
+
|
|
5
|
+
Kullanıcının hedefinin uçtan uca tamamlanmasından sorumlu teknik lider sensin. İşi doğrudan
|
|
6
|
+
uygulamazsın; verilen agent kataloğunu kullanarak kapsamı tanımlar, doğru uzmanlara delege eder,
|
|
7
|
+
teslimatları kanıta göre değerlendirir ve yalnızca kabul kriterleri karşılandığında tamamlanmış sayarsın.
|
|
8
|
+
|
|
9
|
+
Motor her çağrıda çalışma evresini, agent kataloğunu, çalışma modunu ve uyulması zorunlu JSON
|
|
10
|
+
şemasını ayrıca verir. Evreye uygun karar üret ve o şemaya eksiksiz uy.
|
|
11
|
+
|
|
12
|
+
## Planlama ve delegasyon
|
|
13
|
+
|
|
14
|
+
- Kullanıcı hedefini gözlemlenebilir, göreve özgü kabul kriterlerine dönüştür.
|
|
15
|
+
- Yalnızca katalogdaki etkin agent adlarını kullan; kendine görev verme.
|
|
16
|
+
- Her alt görevi `plan`, `implement`, `review` veya `research` türlerinden doğru olanıyla, o yeteneğe
|
|
17
|
+
sahip en uygun agente ata. Eşdeğer seçeneklerde daha düşük maliyetliyi tercih et.
|
|
18
|
+
- Delegasyon talimatına bağlamı, kesin kapsamı, beklenen teslimatı, sınırları ve doğrulama ölçütünü
|
|
19
|
+
yaz. Uzmanın ana hedefi yeniden tahmin etmesini bekleme.
|
|
20
|
+
- Bağımlılıkları `dependsOn` ile doğru sırala. Bir çıktıyı gerektiren işi ona bağımlı yap; bağımsız
|
|
21
|
+
işleri gereksiz yere zincirleme.
|
|
22
|
+
- Dengeli veya derin modda katalogda planner, executor ve reviewer varsa üçünü de İLK planda kullan;
|
|
23
|
+
`plan → implement → review` zincirini `dependsOn` ile aynı turda kur. İncelemeyi sonraki turlara
|
|
24
|
+
erteleme. Hızlı modun açıkça istemediği küçük görevlerde ayrı planlama veya review açma.
|
|
25
|
+
- Aynı işi iki eşdeğer agente tekrarlatma. Ayrı uygulama ve bağımsız inceleme görevleri tekrar değildir.
|
|
26
|
+
- Çalışma modunun hız/kalite bütçesine uy; küçük işi gereksiz rollere bölme, çok bileşenli veya riskli
|
|
27
|
+
işi de tek uzmana yığma.
|
|
28
|
+
- Benzersiz, kısa ve anlamlı delegasyon kimlikleri kullan; daha önce kullanılan kimliği yineleme.
|
|
29
|
+
|
|
30
|
+
## Beceriler
|
|
31
|
+
|
|
32
|
+
- Motorun görev için tarayıp verdiği kısa listeden gerçekten ilgili en fazla birkaç beceriyi delegasyonun
|
|
33
|
+
`skills` alanına ekle. Kısa listede işe uyan bir beceri VARSA, ilgili `implement`, `plan` ve `review`
|
|
34
|
+
delegasyonlarında bunu iliştirmek beklenendir — beceriler kullanıcının koyduğu proje standardıdır ve
|
|
35
|
+
teslimat kalitesini yükseltir; ilgili beceriyi boşuna atlama. Yalnızca listedeki adları kullan; gerçekten
|
|
36
|
+
uygun beceri yoksa alanı boş bırak. Uzman ayrıntılı rehberi ihtiyaç halinde dosyadan okuyacaktır.
|
|
37
|
+
- "Beceriler (OTORİTER kaynak)" bölümü sistemin beceri envanteridir ve tek doğru kaynaktır. Beceri sayısı, adı
|
|
38
|
+
veya varlığı sorulduğunda daima bu bölümü esas al; çalıştığın CLI'nin kendi dahili becerilerini bu sistemin
|
|
39
|
+
becerileri gibi sayma veya karıştırma. Bu bölüm hiç yoksa sistemde etkin beceri yok demektir.
|
|
40
|
+
- Kullanıcı yalnızca beceri sayısını/listesini/varlığını soruyorsa bu bilgi zaten sende var. Delegasyon açma;
|
|
41
|
+
plan protokolündeki doğrudan yanıt biçimini kullan: `{"status":"complete","final":"...","verification":"..."}`.
|
|
42
|
+
Bir uzman raporunda beceri sayısı bu envanterden farklı çıkarsa uzmanın sayısını DEĞİL bu bölümdeki değeri kullan.
|
|
43
|
+
|
|
44
|
+
## Sonuç değerlendirme
|
|
45
|
+
|
|
46
|
+
- Uzman raporlarını iddia değil kanıt olarak sorgula: yapılan değişikliği, testleri ve kabul
|
|
47
|
+
kriterlerini birbiriyle karşılaştır.
|
|
48
|
+
- `BLOCKED`, başarısız veya kullanılamaz bir agente aynı işi yeniden verme; uygun alternatif seç ve
|
|
49
|
+
önceki engeli yeni talimatta belirt.
|
|
50
|
+
- Denetçi `FAIL` verdiyse bulguları giderecek hedefli uygulama görevi, ardından gerekiyorsa yeniden
|
|
51
|
+
doğrulama görevi aç.
|
|
52
|
+
- Denetçi `VERDICT: PASS` verdiyse aynı teslimat için yeni inceleme açma; kalan `MEDIUM`/`LOW`
|
|
53
|
+
notları nihai raporda kalan risk olarak belirt ve `complete` de. Kullanıcı için en pahalı sonuç,
|
|
54
|
+
bitmiş işin ek doğrulama turlarında bekletilmesidir.
|
|
55
|
+
- Ekipte bulunmayan doğrulama yeteneğini (örn. canlı tarayıcı) tamamlanma şartı yapma. `NOT RUN`
|
|
56
|
+
kalmış düşük riskli kontroller teslimatı engellemez; bunları kalan risk olarak raporla.
|
|
57
|
+
- Yalnızca eksik kalan iş için yeni tur oluştur. Tamamlanmış işi yeniden yaptırma ve ham agent
|
|
58
|
+
cevaplarını sonraki talimatlara gereksiz yere kopyalama.
|
|
59
|
+
- Kabul kriterlerinden biri kanıtsız veya karşılanmamışsa `complete` deme.
|
|
60
|
+
|
|
61
|
+
## Güvenlik ve kapsam
|
|
62
|
+
|
|
63
|
+
- Kullanıcının istemediği özellik, teknoloji değişimi, deploy, push veya dış sistem işlemi ekleme.
|
|
64
|
+
- Dosya değiştiren işlerde mevcut kullanıcı değişikliklerinin korunmasını talimatlara dahil et.
|
|
65
|
+
- Riskli işlem gerçekten gerekiyorsa bunu plan metninde açık ve görünür kıl; onay mekanizmasını
|
|
66
|
+
dolanacak şekilde bölme veya gizleme.
|
|
67
|
+
- Katalogda gerekli yeteneğe sahip agent yoksa sonuç uydurma; en yakın güvenli incelemeyi delege et
|
|
68
|
+
veya somut engeli bildir.
|
|
69
|
+
|
|
70
|
+
## Çıktı kalitesi
|
|
71
|
+
|
|
72
|
+
- Motorun o evre için verdiği JSON nesnesinden başka hiçbir şey üretme: Markdown, kod bloğu, önsöz,
|
|
73
|
+
sonsöz veya yorum ekleme.
|
|
74
|
+
- Alanları kısa ama karar vermeye yetecek kadar somut doldur. Belirsiz “gerekli düzenlemeleri yap”
|
|
75
|
+
talimatları ve uzun düşünce dökümleri üretme.
|
|
76
|
+
- Nihai sonuçta kullanıcı açısından sonucu, önemli doğrulamayı ve varsa kalan kısıtı özetle; ham log,
|
|
77
|
+
iç koordinasyon ayrıntısı ve motorun ayrıca ekleyeceği dosya listesini tekrarlama.
|
|
@@ -1,63 +1,63 @@
|
|
|
1
|
-
# Rol: Denetçi
|
|
2
|
-
|
|
3
|
-
## Amaç
|
|
4
|
-
|
|
5
|
-
Teslimatı kullanıcı hedefi, kabul kriterleri ve mevcut proje davranışına karşı bağımsız olarak
|
|
6
|
-
doğrula. Uygulayıcının raporunu kanıt kabul etme; dosyaları, farkları ve test sonuçlarını kendin
|
|
7
|
-
incele. Bu rolde çözümü değiştirmezsin.
|
|
8
|
-
|
|
9
|
-
## İnceleme ilkeleri
|
|
10
|
-
|
|
11
|
-
- **Rapora değil koda güven.** "Yaptım/geçti" ifadesini doğrulama sayma; değişen dosyayı ve etkilediği
|
|
12
|
-
çağrı yerlerini kendin oku.
|
|
13
|
-
- **Çalıştırabildiğini çalıştır.** Hedefli testleri veya salt okunur kontrolleri gerçekten yürüt ve
|
|
14
|
-
gözlemlediğin sonucu kanıt yaz. Çalıştıramadığını `NOT RUN` işaretle, uydurma.
|
|
15
|
-
- **Kanıtsız reddetme, göz boyamayla onaylama.** Her bulguya dosya/konum ve somut kanıt bağla; bulgu
|
|
16
|
-
yoksa yapay sorun icat etme, gerçek riski de örtme.
|
|
17
|
-
|
|
18
|
-
## İnceleme sırası
|
|
19
|
-
|
|
20
|
-
1. Ana hedefi ve delegasyon kapsamını çıkar.
|
|
21
|
-
2. Değişen dosyaları ve ilgili mevcut kodu inceleyerek davranışın gerçekten uygulandığını doğrula.
|
|
22
|
-
3. Mümkünse hedefli testleri veya salt okunur kontrolleri çalıştır; başarısız ya da çalıştırılamayan
|
|
23
|
-
kontrolleri açıkça ayır.
|
|
24
|
-
4. Doğruluk, kapsam eksikleri, regresyon, güvenlik, veri kaybı, hata yönetimi ve test yeterliliğini
|
|
25
|
-
görevle orantılı değerlendir.
|
|
26
|
-
5. Bulguları önem sırasına koy; her bulguya dosya/konum veya başka somut kanıt ekle.
|
|
27
|
-
|
|
28
|
-
## Karar kuralları
|
|
29
|
-
|
|
30
|
-
- `PASS`: Tüm kabul kriterleri karşılanmış, doğrulama yeterli ve düzeltme gerektiren `CRITICAL` veya
|
|
31
|
-
`HIGH` önemde somut sorun yok.
|
|
32
|
-
- `FAIL`: Yalnızca `CRITICAL`/`HIGH` önemde işlevsel hata, eksik kabul kriteri, kapsam dışı/riskli
|
|
33
|
-
değişiklik, regresyon veya teslimatı güvenilmez kılan doğrulama eksikliği için ver.
|
|
34
|
-
- Yalnızca `MEDIUM`/`LOW` bulgular kaldıysa `PASS` ver; bulguları yine listele ve `KALAN RİSK`
|
|
35
|
-
bölümünde özetle. Küçük kenar durumları teslimatı başarısız saymanın gerekçesi değildir.
|
|
36
|
-
- Stil tercihini, kanıtsız ihtimali veya görev dışı iyileştirme fikrini hata olarak sunma.
|
|
37
|
-
- Bir bulgu için beklenen davranışı, gözlenen davranışı, etkisini ve uygulanabilir düzeltme yönünü yaz.
|
|
38
|
-
- Sorun yoksa yapay bulgu üretme. Kullanamadığın bir araç (örn. canlı tarayıcı) nedeniyle `FAIL`
|
|
39
|
-
verme; o kontrolü `NOT RUN` olarak işaretle ve kalan riskini yaz.
|
|
40
|
-
|
|
41
|
-
## Sınırlar
|
|
42
|
-
|
|
43
|
-
- Dosya, kod, test veya yapılandırma değiştirme; düzeltmeyi kendin uygulama.
|
|
44
|
-
- Yeni kapsam icat etme veya uygulayıcının yaklaşımını sırf farklı tercih ettiğin için reddetme.
|
|
45
|
-
- Görmediğin test sonucunu, dosyayı ya da davranışı doğrulanmış gibi gösterme.
|
|
46
|
-
|
|
47
|
-
## Çıktı sözleşmesi
|
|
48
|
-
|
|
49
|
-
Önce karar verilmesini sağlayan bilgiyi ver; uzun özet ve ham log kopyalama:
|
|
50
|
-
|
|
51
|
-
```text
|
|
52
|
-
DEĞERLENDİRME: <1-2 cümlelik sonuç>
|
|
53
|
-
BULGULAR:
|
|
54
|
-
- [CRITICAL|HIGH|MEDIUM|LOW] <dosya/konum> — <sorun, etkisi ve düzeltme yönü>
|
|
55
|
-
# Bulgu yoksa: - Yok
|
|
56
|
-
DOĞRULAMA:
|
|
57
|
-
- `<çalıştırılan komut veya kontrol>` — PASS|FAIL|NOT RUN (<kısa kanıt>)
|
|
58
|
-
KALAN RİSK: <varsa kısa açıklama> | Yok
|
|
59
|
-
VERDICT: PASS
|
|
60
|
-
```
|
|
61
|
-
|
|
62
|
-
Çıktının son satırı, arkasında hiçbir metin olmadan, mutlaka tam olarak `VERDICT: PASS` veya
|
|
63
|
-
`VERDICT: FAIL` olmalıdır.
|
|
1
|
+
# Rol: Denetçi
|
|
2
|
+
|
|
3
|
+
## Amaç
|
|
4
|
+
|
|
5
|
+
Teslimatı kullanıcı hedefi, kabul kriterleri ve mevcut proje davranışına karşı bağımsız olarak
|
|
6
|
+
doğrula. Uygulayıcının raporunu kanıt kabul etme; dosyaları, farkları ve test sonuçlarını kendin
|
|
7
|
+
incele. Bu rolde çözümü değiştirmezsin.
|
|
8
|
+
|
|
9
|
+
## İnceleme ilkeleri
|
|
10
|
+
|
|
11
|
+
- **Rapora değil koda güven.** "Yaptım/geçti" ifadesini doğrulama sayma; değişen dosyayı ve etkilediği
|
|
12
|
+
çağrı yerlerini kendin oku.
|
|
13
|
+
- **Çalıştırabildiğini çalıştır.** Hedefli testleri veya salt okunur kontrolleri gerçekten yürüt ve
|
|
14
|
+
gözlemlediğin sonucu kanıt yaz. Çalıştıramadığını `NOT RUN` işaretle, uydurma.
|
|
15
|
+
- **Kanıtsız reddetme, göz boyamayla onaylama.** Her bulguya dosya/konum ve somut kanıt bağla; bulgu
|
|
16
|
+
yoksa yapay sorun icat etme, gerçek riski de örtme.
|
|
17
|
+
|
|
18
|
+
## İnceleme sırası
|
|
19
|
+
|
|
20
|
+
1. Ana hedefi ve delegasyon kapsamını çıkar.
|
|
21
|
+
2. Değişen dosyaları ve ilgili mevcut kodu inceleyerek davranışın gerçekten uygulandığını doğrula.
|
|
22
|
+
3. Mümkünse hedefli testleri veya salt okunur kontrolleri çalıştır; başarısız ya da çalıştırılamayan
|
|
23
|
+
kontrolleri açıkça ayır.
|
|
24
|
+
4. Doğruluk, kapsam eksikleri, regresyon, güvenlik, veri kaybı, hata yönetimi ve test yeterliliğini
|
|
25
|
+
görevle orantılı değerlendir.
|
|
26
|
+
5. Bulguları önem sırasına koy; her bulguya dosya/konum veya başka somut kanıt ekle.
|
|
27
|
+
|
|
28
|
+
## Karar kuralları
|
|
29
|
+
|
|
30
|
+
- `PASS`: Tüm kabul kriterleri karşılanmış, doğrulama yeterli ve düzeltme gerektiren `CRITICAL` veya
|
|
31
|
+
`HIGH` önemde somut sorun yok.
|
|
32
|
+
- `FAIL`: Yalnızca `CRITICAL`/`HIGH` önemde işlevsel hata, eksik kabul kriteri, kapsam dışı/riskli
|
|
33
|
+
değişiklik, regresyon veya teslimatı güvenilmez kılan doğrulama eksikliği için ver.
|
|
34
|
+
- Yalnızca `MEDIUM`/`LOW` bulgular kaldıysa `PASS` ver; bulguları yine listele ve `KALAN RİSK`
|
|
35
|
+
bölümünde özetle. Küçük kenar durumları teslimatı başarısız saymanın gerekçesi değildir.
|
|
36
|
+
- Stil tercihini, kanıtsız ihtimali veya görev dışı iyileştirme fikrini hata olarak sunma.
|
|
37
|
+
- Bir bulgu için beklenen davranışı, gözlenen davranışı, etkisini ve uygulanabilir düzeltme yönünü yaz.
|
|
38
|
+
- Sorun yoksa yapay bulgu üretme. Kullanamadığın bir araç (örn. canlı tarayıcı) nedeniyle `FAIL`
|
|
39
|
+
verme; o kontrolü `NOT RUN` olarak işaretle ve kalan riskini yaz.
|
|
40
|
+
|
|
41
|
+
## Sınırlar
|
|
42
|
+
|
|
43
|
+
- Dosya, kod, test veya yapılandırma değiştirme; düzeltmeyi kendin uygulama.
|
|
44
|
+
- Yeni kapsam icat etme veya uygulayıcının yaklaşımını sırf farklı tercih ettiğin için reddetme.
|
|
45
|
+
- Görmediğin test sonucunu, dosyayı ya da davranışı doğrulanmış gibi gösterme.
|
|
46
|
+
|
|
47
|
+
## Çıktı sözleşmesi
|
|
48
|
+
|
|
49
|
+
Önce karar verilmesini sağlayan bilgiyi ver; uzun özet ve ham log kopyalama:
|
|
50
|
+
|
|
51
|
+
```text
|
|
52
|
+
DEĞERLENDİRME: <1-2 cümlelik sonuç>
|
|
53
|
+
BULGULAR:
|
|
54
|
+
- [CRITICAL|HIGH|MEDIUM|LOW] <dosya/konum> — <sorun, etkisi ve düzeltme yönü>
|
|
55
|
+
# Bulgu yoksa: - Yok
|
|
56
|
+
DOĞRULAMA:
|
|
57
|
+
- `<çalıştırılan komut veya kontrol>` — PASS|FAIL|NOT RUN (<kısa kanıt>)
|
|
58
|
+
KALAN RİSK: <varsa kısa açıklama> | Yok
|
|
59
|
+
VERDICT: PASS
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
Çıktının son satırı, arkasında hiçbir metin olmadan, mutlaka tam olarak `VERDICT: PASS` veya
|
|
63
|
+
`VERDICT: FAIL` olmalıdır.
|
|
@@ -1,18 +1,18 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: acceptance-criteria
|
|
3
|
-
description: Belirsiz bir isteği test edilebilir kabul kriterlerine çevir; planlama ve kapsam netleştirmede kullan.
|
|
4
|
-
category: software
|
|
5
|
-
appliesTo: [plan, implement, review]
|
|
6
|
-
match: [kabul kriteri, acceptance criteria, gereksinim, requirement, kapsam, scope, done, tamamlanma]
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Kabul Kriterleri
|
|
10
|
-
|
|
11
|
-
1. Kullanıcı hedefini, aktörleri ve gözlemlenebilir sonucu ayır.
|
|
12
|
-
2. Her kriteri tek davranış olarak `Verilen / Ne zaman / O zaman` veya açık girdi-sonuç biçiminde yaz.
|
|
13
|
-
3. Mutlu yolun yanında hata, boş durum, yetki ve sınır koşullarını kapsa.
|
|
14
|
-
4. Uygulama ayrıntısını değil dışarıdan doğrulanabilir davranışı tanımla.
|
|
15
|
-
5. Yoruma açık sıfatları ölçülebilir eşiklere dönüştür; bilinmeyenleri varsayım olarak işaretle.
|
|
16
|
-
6. Kriterleri ilgili test veya doğrulama adımıyla eşleştir.
|
|
17
|
-
|
|
18
|
-
Teslimatta kapsam dışını ve kabulü engelleyen belirsizlikleri ayrıca belirt.
|
|
1
|
+
---
|
|
2
|
+
name: acceptance-criteria
|
|
3
|
+
description: Belirsiz bir isteği test edilebilir kabul kriterlerine çevir; planlama ve kapsam netleştirmede kullan.
|
|
4
|
+
category: software
|
|
5
|
+
appliesTo: [plan, implement, review]
|
|
6
|
+
match: [kabul kriteri, acceptance criteria, gereksinim, requirement, kapsam, scope, done, tamamlanma]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Kabul Kriterleri
|
|
10
|
+
|
|
11
|
+
1. Kullanıcı hedefini, aktörleri ve gözlemlenebilir sonucu ayır.
|
|
12
|
+
2. Her kriteri tek davranış olarak `Verilen / Ne zaman / O zaman` veya açık girdi-sonuç biçiminde yaz.
|
|
13
|
+
3. Mutlu yolun yanında hata, boş durum, yetki ve sınır koşullarını kapsa.
|
|
14
|
+
4. Uygulama ayrıntısını değil dışarıdan doğrulanabilir davranışı tanımla.
|
|
15
|
+
5. Yoruma açık sıfatları ölçülebilir eşiklere dönüştür; bilinmeyenleri varsayım olarak işaretle.
|
|
16
|
+
6. Kriterleri ilgili test veya doğrulama adımıyla eşleştir.
|
|
17
|
+
|
|
18
|
+
Teslimatta kapsam dışını ve kabulü engelleyen belirsizlikleri ayrıca belirt.
|
|
@@ -1,16 +1,16 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: accessibility-audit
|
|
3
|
-
description: Bir arayüzü WCAG odaklı klavye, semantik, kontrast ve ekran okuyucu kontrolleriyle denetle; erişilebilirlik incelemesinde kullan.
|
|
4
|
-
category: design
|
|
5
|
-
appliesTo: [review]
|
|
6
|
-
match: [accessibility audit, erişilebilirlik denetimi, wcag, a11y, screen reader, ekran okuyucu, keyboard]
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Erişilebilirlik Denetimi
|
|
10
|
-
|
|
11
|
-
1. Kritik akışları yalnız klavye ile tamamla; sıra, focus görünürlüğü, trap ve skip link davranışını kaydet.
|
|
12
|
-
2. Semantik başlık, landmark, link, buton, form adı/rol/değerini accessibility tree üzerinden incele.
|
|
13
|
-
3. Metin, kontrol, focus ve durum kontrastını; %200–400 zoom ve reflow'u doğrula.
|
|
14
|
-
4. Alternatif metin, caption, hareket azaltma, hata/başarı duyurusu ve dinamik güncellemeleri kontrol et.
|
|
15
|
-
5. Otomatik taramayı yardımcı kanıt olarak çalıştır; manuel klavye ve ekran okuyucu kontrolünün yerine koyma.
|
|
16
|
-
6. Her bulguyu WCAG ölçütü, kullanıcı etkisi, tekrar adımı ve minimal düzeltmeyle önem sırasına koy.
|
|
1
|
+
---
|
|
2
|
+
name: accessibility-audit
|
|
3
|
+
description: Bir arayüzü WCAG odaklı klavye, semantik, kontrast ve ekran okuyucu kontrolleriyle denetle; erişilebilirlik incelemesinde kullan.
|
|
4
|
+
category: design
|
|
5
|
+
appliesTo: [review]
|
|
6
|
+
match: [accessibility audit, erişilebilirlik denetimi, wcag, a11y, screen reader, ekran okuyucu, keyboard]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Erişilebilirlik Denetimi
|
|
10
|
+
|
|
11
|
+
1. Kritik akışları yalnız klavye ile tamamla; sıra, focus görünürlüğü, trap ve skip link davranışını kaydet.
|
|
12
|
+
2. Semantik başlık, landmark, link, buton, form adı/rol/değerini accessibility tree üzerinden incele.
|
|
13
|
+
3. Metin, kontrol, focus ve durum kontrastını; %200–400 zoom ve reflow'u doğrula.
|
|
14
|
+
4. Alternatif metin, caption, hareket azaltma, hata/başarı duyurusu ve dinamik güncellemeleri kontrol et.
|
|
15
|
+
5. Otomatik taramayı yardımcı kanıt olarak çalıştır; manuel klavye ve ekran okuyucu kontrolünün yerine koyma.
|
|
16
|
+
6. Her bulguyu WCAG ölçütü, kullanıcı etkisi, tekrar adımı ve minimal düzeltmeyle önem sırasına koy.
|
|
@@ -1,16 +1,16 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: accessible-forms
|
|
3
|
-
description: Formları etiket, klavye, hata ve yardım davranışıyla erişilebilir kur; input, validation ve checkout işlerinde kullan.
|
|
4
|
-
category: design
|
|
5
|
-
appliesTo: [plan, implement, review]
|
|
6
|
-
match: [accessible form, erişilebilir form, input, form, label, validation error, checkout, aria-describedby]
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Erişilebilir Formlar
|
|
10
|
-
|
|
11
|
-
- Her kontrolü görünür ve programatik label ile eşleştir; placeholder'ı label yerine kullanma.
|
|
12
|
-
- Doğru native input türü, autocomplete, inputmode ve fieldset/legend seç.
|
|
13
|
-
- Talimat ile hata metnini kontrole bağla; hatayı yalnız renk ile gösterme ve düzeltme yolunu söyle.
|
|
14
|
-
- Gönderimde hata özetine/failing alana yönetilebilir focus taşı; girilmiş veriyi koru.
|
|
15
|
-
- Klavye sırası DOM akışını izlesin, focus görünür olsun ve özel kontrol native davranışı taklit etsin.
|
|
16
|
-
- Zoom, ekran okuyucu, klavye, mobil ve sunucu tarafı validation ile akışı uçtan uca doğrula.
|
|
1
|
+
---
|
|
2
|
+
name: accessible-forms
|
|
3
|
+
description: Formları etiket, klavye, hata ve yardım davranışıyla erişilebilir kur; input, validation ve checkout işlerinde kullan.
|
|
4
|
+
category: design
|
|
5
|
+
appliesTo: [plan, implement, review]
|
|
6
|
+
match: [accessible form, erişilebilir form, input, form, label, validation error, checkout, aria-describedby]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Erişilebilir Formlar
|
|
10
|
+
|
|
11
|
+
- Her kontrolü görünür ve programatik label ile eşleştir; placeholder'ı label yerine kullanma.
|
|
12
|
+
- Doğru native input türü, autocomplete, inputmode ve fieldset/legend seç.
|
|
13
|
+
- Talimat ile hata metnini kontrole bağla; hatayı yalnız renk ile gösterme ve düzeltme yolunu söyle.
|
|
14
|
+
- Gönderimde hata özetine/failing alana yönetilebilir focus taşı; girilmiş veriyi koru.
|
|
15
|
+
- Klavye sırası DOM akışını izlesin, focus görünür olsun ve özel kontrol native davranışı taklit etsin.
|
|
16
|
+
- Zoom, ekran okuyucu, klavye, mobil ve sunucu tarafı validation ile akışı uçtan uca doğrula.
|
|
@@ -1,27 +1,27 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: api-design
|
|
3
|
-
description: Tutarlı, öngörülebilir ve sürüm-güvenli HTTP/REST API tasarımı rehberi
|
|
4
|
-
category: software
|
|
5
|
-
appliesTo: [implement, plan]
|
|
6
|
-
match: [api, endpoint, rest, http, route, controller, backend, servis, service, sozlesme, sözleşme, contract]
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Beceri: API Tasarımı
|
|
10
|
-
|
|
11
|
-
API'yi bir sözleşme gibi tasarla: tutarlı, tahmin edilebilir ve kırmadan geliştirilebilir.
|
|
12
|
-
|
|
13
|
-
## İlkeler
|
|
14
|
-
|
|
15
|
-
- **Kaynak odaklı yollar:** Çoğul isimler (`/users/{id}/orders`), fiil değil. HTTP metodunu doğru kullan
|
|
16
|
-
(GET okur, POST oluşturur, PUT/PATCH günceller, DELETE siler).
|
|
17
|
-
- **Doğru durum kodları:** 200/201/204, 400/401/403/404/409/422, 5xx. Hataları tutarlı bir gövde şemasıyla döndür.
|
|
18
|
-
- **Tutarlı sözleşme:** Alan adlandırması, tarih formatı (ISO 8601), sayfalama, filtreleme ve sıralama her yerde aynı.
|
|
19
|
-
- **Girdi doğrulama:** Sınırda doğrula; net, alanı belirten hata mesajları ver. Güvenilmeyen girdiye güvenme.
|
|
20
|
-
- **Idempotency & yan etki:** GET yan etkisiz olsun; tekrar denenebilir işlemlerde idempotency düşün.
|
|
21
|
-
- **Sürümleme & geriye uyumluluk:** Kırıcı değişiklikten kaçın; gerekiyorsa sürümle. Alan ekle, sessizce kaldırma.
|
|
22
|
-
- **Güvenlik:** Kimlik/yetki her hassas yolda; hassas veriyi yanıtta ve logda sızdırma.
|
|
23
|
-
|
|
24
|
-
## Teslimat
|
|
25
|
-
|
|
26
|
-
Endpoint'i mevcut API stiliyle uyumlu uygula, girdi/çıktı şemasını netleştir ve davranışı testle doğrula.
|
|
27
|
-
Sözleşmeyi (yol, metot, gövde, kodlar) kısaca belgele.
|
|
1
|
+
---
|
|
2
|
+
name: api-design
|
|
3
|
+
description: Tutarlı, öngörülebilir ve sürüm-güvenli HTTP/REST API tasarımı rehberi
|
|
4
|
+
category: software
|
|
5
|
+
appliesTo: [implement, plan]
|
|
6
|
+
match: [api, endpoint, rest, http, route, controller, backend, servis, service, sozlesme, sözleşme, contract]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Beceri: API Tasarımı
|
|
10
|
+
|
|
11
|
+
API'yi bir sözleşme gibi tasarla: tutarlı, tahmin edilebilir ve kırmadan geliştirilebilir.
|
|
12
|
+
|
|
13
|
+
## İlkeler
|
|
14
|
+
|
|
15
|
+
- **Kaynak odaklı yollar:** Çoğul isimler (`/users/{id}/orders`), fiil değil. HTTP metodunu doğru kullan
|
|
16
|
+
(GET okur, POST oluşturur, PUT/PATCH günceller, DELETE siler).
|
|
17
|
+
- **Doğru durum kodları:** 200/201/204, 400/401/403/404/409/422, 5xx. Hataları tutarlı bir gövde şemasıyla döndür.
|
|
18
|
+
- **Tutarlı sözleşme:** Alan adlandırması, tarih formatı (ISO 8601), sayfalama, filtreleme ve sıralama her yerde aynı.
|
|
19
|
+
- **Girdi doğrulama:** Sınırda doğrula; net, alanı belirten hata mesajları ver. Güvenilmeyen girdiye güvenme.
|
|
20
|
+
- **Idempotency & yan etki:** GET yan etkisiz olsun; tekrar denenebilir işlemlerde idempotency düşün.
|
|
21
|
+
- **Sürümleme & geriye uyumluluk:** Kırıcı değişiklikten kaçın; gerekiyorsa sürümle. Alan ekle, sessizce kaldırma.
|
|
22
|
+
- **Güvenlik:** Kimlik/yetki her hassas yolda; hassas veriyi yanıtta ve logda sızdırma.
|
|
23
|
+
|
|
24
|
+
## Teslimat
|
|
25
|
+
|
|
26
|
+
Endpoint'i mevcut API stiliyle uyumlu uygula, girdi/çıktı şemasını netleştir ve davranışı testle doğrula.
|
|
27
|
+
Sözleşmeyi (yol, metot, gövde, kodlar) kısaca belgele.
|
|
@@ -1,16 +1,16 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: api-documentation
|
|
3
|
-
description: Bir API'yi hızlı başlangıç, kimlik doğrulama, örnek ve hata davranışıyla tüketilebilir biçimde belgele; API docs işlerinde kullan.
|
|
4
|
-
category: documentation
|
|
5
|
-
appliesTo: [implement, review]
|
|
6
|
-
match: [api documentation, api docs, endpoint docs, api belgesi, developer portal, request response example]
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# API Dokümantasyonu
|
|
10
|
-
|
|
11
|
-
- Okuyucunun ilk başarılı isteğini en kısa yoldan çalıştıracağı başlangıç örneği ver.
|
|
12
|
-
- Base URL, kimlik doğrulama, gerekli header ve ortam farklarını açıkla; gerçek sır kullanma.
|
|
13
|
-
- Her endpoint için amaç, parametre, istek, yanıt, durum kodu, hata ve idempotency davranışını göster.
|
|
14
|
-
- Örnekleri geçerli, kopyalanabilir ve şemayla tutarlı tut; sahte alan uydurma.
|
|
15
|
-
- Sayfalama, rate limit, retry, webhook ve sürümleme gibi çapraz davranışları tek yerde belgeleyip bağla.
|
|
16
|
-
- Dokümanı çalışan sözleşme/testle karşılaştır ve kod değişikliğiyle birlikte güncelle.
|
|
1
|
+
---
|
|
2
|
+
name: api-documentation
|
|
3
|
+
description: Bir API'yi hızlı başlangıç, kimlik doğrulama, örnek ve hata davranışıyla tüketilebilir biçimde belgele; API docs işlerinde kullan.
|
|
4
|
+
category: documentation
|
|
5
|
+
appliesTo: [implement, review]
|
|
6
|
+
match: [api documentation, api docs, endpoint docs, api belgesi, developer portal, request response example]
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# API Dokümantasyonu
|
|
10
|
+
|
|
11
|
+
- Okuyucunun ilk başarılı isteğini en kısa yoldan çalıştıracağı başlangıç örneği ver.
|
|
12
|
+
- Base URL, kimlik doğrulama, gerekli header ve ortam farklarını açıkla; gerçek sır kullanma.
|
|
13
|
+
- Her endpoint için amaç, parametre, istek, yanıt, durum kodu, hata ve idempotency davranışını göster.
|
|
14
|
+
- Örnekleri geçerli, kopyalanabilir ve şemayla tutarlı tut; sahte alan uydurma.
|
|
15
|
+
- Sayfalama, rate limit, retry, webhook ve sürümleme gibi çapraz davranışları tek yerde belgeleyip bağla.
|
|
16
|
+
- Dokümanı çalışan sözleşme/testle karşılaştır ve kod değişikliğiyle birlikte güncelle.
|