Spec Kit di Monorepo Golang: Satu Konstitusi untuk Banyak Service
Cara menggunakan GitHub Spec Kit di monorepo Golang. Setup satu shared constitution untuk banyak service dengan konfigurasi per-service dan workflow yang efisien.
Spec Kit di Monorepo Go: Satu Konstitusi, Banyak Service
Menerapkan Spec Kit di monorepo Golang punya tantangan unik: satu repo berisi banyak service yang masing-masing punya domain, tech stack, dan tim berbeda — tapi semuanya tetap perlu berbagi prinsip arsitektur yang sama. Kabar baiknya, Spec Kit mendukung skenario ini secara native lewat hierarki constitution dan cross-service feature spec. Di artikel ini kita bedah cara menatanya agar konsisten sekaligus fleksibel per service.
17.1 Struktur Monorepo dengan Spec Kit
Fondasi dari semuanya adalah struktur direktori yang jelas: mana yang shared di root, dan mana yang spesifik per service. Pohon direktori berikut memperlihatkan bagaimana .specify/ root berdampingan dengan .specify/ di tiap service.
1santekno-shop-monorepo/
2├── .specify/ ← Shared: constitution dan cross-service features
3│ ├── constitution.md ← Prinsip untuk SEMUA service
4│ ├── .speckit-config.yaml ← Config root (default)
5│ └── features/ ← Cross-service feature specs
6│ └── order-notification/ ← Feature yang melibatkan multiple service
7│ ├── spec.md
8│ ├── plan-order.md
9│ └── plan-notification.md
10│
11├── services/
12│ ├── order-service/
13│ │ ├── .specify/ ← Service-specific specs
14│ │ │ ├── .speckit-config.yaml ← Override config untuk order-service
15│ │ │ └── features/
16│ │ │ └── cancel-order/
17│ │ ├── CLAUDE.md ← Service-specific AI context
18│ │ ├── go.mod
19│ │ └── internal/
20│ │
21│ ├── product-service/
22│ │ ├── .specify/
23│ │ ├── CLAUDE.md
24│ │ └── go.mod
25│ │
26│ └── notification-service/
27│ ├── .specify/
28│ ├── CLAUDE.md
29│ └── go.mod
30│
31├── libs/ ← Shared libraries
32│ └── domain-events/
33│ └── go.mod
34│
35└── go.work ← Go workspace fileKunci struktur ini adalah pemisahan dua level: .specify/ di root menyimpan constitution universal dan fitur lintas-service, sementara tiap service punya .specify/ sendiri untuk spec dan config lokalnya. Pemisahan inilah yang memungkinkan konsistensi global tanpa mengorbankan otonomi per service.
17.2 Constitution Hierarki: Root vs Service-Level
Root constitution memuat prinsip yang berlaku untuk semua service tanpa kecuali. Contoh berikut menunjukkan aturan universal — format error code, penanganan uang, sampai standar komunikasi antar-service.
1# Root constitution.md — berlaku untuk SEMUA service
2
3## Universal Principles
4- Error code format: UPPERCASE_SNAKE_CASE
5- Monetary values: int64 cents, NEVER float64
6- UUID untuk primary keys
7- Context propagation: selalu ctx sebagai parameter pertama
8
9## Inter-Service Communication
10- REST untuk sync calls (dengan timeout)
11- Kafka untuk async events (at-least-once delivery)
12- gRPC untuk internal service calls yang butuh performance tinggi
13- Circuit breaker WAJIB untuk semua sync external calls
14
15## API Versioning
16- URL versioning: /api/v1/, /api/v2/
17- Breaking changes butuh major version bump
18- Deprecated endpoints: tetap ada minimal 3 bulan sebelum dihapusAturan-aturan universal ini adalah “hukum negara” yang mengikat semua service. Di atasnya, tiap service boleh menambahkan aturan lokal lewat config yang meng-inherit root, seperti contoh order-service berikut.
1# services/order-service/.specify/.speckit-config.yaml
2# Override untuk order-service
3
4constitution:
5 # Inherit root constitution
6 parent: ../../.specify/constitution.md
7 # Service-specific additions
8 additions: |
9 ## Order Service Specific
10 - Order status flow: PENDING → CONFIRMED → SHIPPED → DELIVERED | CANCELLED
11 - Stock reservation: selalu atomic dengan order creation
12 - Payment timeout: 15 menit dari order creationPerhatikan bahwa order-service hanya menambah (additions), tidak menimpa aturan root. Model inheritance inilah yang mencegah setiap service diam-diam membuat aturan sendiri yang bertentangan dengan prinsip global.
17.3 Running Spec Kit di Monorepo
Spec Kit bisa dijalankan dari beberapa titik, tergantung apakah kamu berada di dalam service atau di root. Tiga opsi berikut menghasilkan hasil yang sama tapi cocok untuk gaya kerja yang berbeda.
1# Option 1: Run dari service directory
2cd services/order-service
3specify feature # menggunakan config dari .specify/.speckit-config.yaml
4 # dan inherit constitution dari ../../.specify/constitution.md
5
6# Option 2: Run dari root dengan flag
7specify feature --service order-service
8
9# Option 3: Run dari root dengan full path config
10specify feature --config services/order-service/.specify/.speckit-config.yamlKetiga opsi ini memberi keluwesan: developer yang fokus di satu service cukup cd ke sana, sementara skrip otomasi di root bisa menargetkan service mana pun lewat flag. Yang penting, config dan constitution yang di-resolve selalu sama, apa pun titik masuknya.
17.4 Cross-Service Feature Specs
Beberapa fitur secara inheren melibatkan lebih dari satu service — misalnya mengirim email saat order dibatalkan. Perintah --cross-service berikut mendeteksi service yang terlibat dan men-generate spec bersama plus plan per service.
1# Dari root directory
2cd santekno-shop-monorepo
3
4# Feature yang melibatkan order-service dan notification-service
5specify feature --cross-service
6
7# Prompt:
8# "Ketika order di-cancel, kirim email notifikasi ke customer"
9#
10# Spec Kit mendeteksi bahwa ini melibatkan:
11# - order-service: event ORDER_CANCELLED
12# - notification-service: consume event, kirim email
13#
14# Output:
15# .specify/features/order-notification/spec.md ← shared spec
16# .specify/features/order-notification/plan-order-service.md
17# .specify/features/order-notification/plan-notification-service.mdYang elegan di sini: ada satu spec.md bersama sebagai sumber kebenaran, tapi tiap service punya plan-nya sendiri. Dengan begitu koordinasi lintas-service terjaga tanpa mencampur adukkan detail implementasi masing-masing service.
17.5 Event Contract Specs
Di monorepo event-driven, kontrak event antar-service harus di-spec-kan seketat kontrak API. Dokumen kontrak berikut mendefinisikan skema, jaminan pengiriman, dan kebijakan breaking change untuk event ORDER_CANCELLED.
1# .specify/contracts/order-cancelled-event.md
2
3# Event Contract: ORDER_CANCELLED
4# Producer: order-service
5# Consumer: notification-service, inventory-service
6# Version: 1.0
7
8## Schema (JSON)
9{
10 "event_type": "ORDER_CANCELLED",
11 "version": "1.0",
12 "event_id": "uuid",
13 "occurred_at": "ISO8601",
14 "data": {
15 "order_id": "uuid",
16 "user_id": "uuid",
17 "user_email": "string",
18 "items": [{
19 "product_id": "uuid",
20 "quantity": "int",
21 "refund_amount_cents": "int64"
22 }],
23 "total_refund_cents": "int64",
24 "cancelled_by": "CUSTOMER | ADMIN | SYSTEM",
25 "cancellation_reason": "string | null"
26 }
27}
28
29## Guarantees
30- At-least-once delivery via Kafka
31- Producer: order-service (after successful DB commit)
32- Partition key: order_id (consumer satu partition per order)
33- Retention: 7 hari
34
35## Breaking Changes Policy
36- Additive changes (new optional field): version tidak naik
37- Field removal atau type change: bump ke ORDER_CANCELLED_V2
38- Both versions co-exist selama 3 bulan (migration window)Kontrak ini memperlakukan event persis seperti public API: skema eksplisit, jaminan delivery, dan aturan versioning yang jelas. Dengan begitu producer dan consumer bisa berevolusi independen tanpa saling merusak — asalkan keduanya patuh pada kontrak.
17.6 Service-to-Service Plan Dependencies
Ketika plan satu service bergantung pada service lain, ketergantungan itu harus tertulis eksplisit di plan. Contoh plan order-service berikut menyatakan dependency ke notification-service beserta urutan deployment-nya.
1# .specify/features/order-notification/plan-order-service.md
2
3## Order Service Changes
4- Add: KafkaOrderCancelledPublisher implementation
5- Modify: CancelOrderUseCase — publish event setelah commit sukses
6- Contract: .specify/contracts/order-cancelled-event.md v1.0
7
8## Dependency on Notification Service
9- Notification service harus siap consume ORDER_CANCELLED sebelum order-service deploy
10- Coordinate deployment order: notification-service DAHULU, lalu order-service
11- Test: publish event dari order-service, verify notification-service consumeMenuliskan “notification-service dahulu, lalu order-service” di dalam plan mengubah pengetahuan implisit menjadi instruksi eksplisit. Inilah cara mencegah insiden klasik: producer sudah publish event yang belum ada consumernya.
17.7 Monorepo CI: Per-Service Spec Audit
Meng-audit seluruh service di setiap PR itu boros. Workflow GitHub Actions berikut mendeteksi service mana yang berubah lalu hanya meng-audit service tersebut lewat matrix strategy.
1# .github/workflows/monorepo-spec-audit.yml
2
3on:
4 pull_request:
5 paths:
6 - 'services/**'
7 - '.specify/**'
8
9jobs:
10 detect-changed-services:
11 runs-on: ubuntu-latest
12 outputs:
13 services: ${{ steps.detect.outputs.services }}
14 steps:
15 - id: detect
16 run: |
17 # Detect which services have changed
18 CHANGED_SERVICES=$(git diff --name-only origin/main... | \
19 grep '^services/' | \
20 cut -d/ -f2 | sort -u | \
21 jq -R -s -c 'split("\n")[:-1]')
22 echo "services=$CHANGED_SERVICES" >> $GITHUB_OUTPUT
23
24 audit-services:
25 needs: detect-changed-services
26 strategy:
27 matrix:
28 service: ${{ fromJson(needs.detect-changed-services.outputs.services) }}
29 runs-on: ubuntu-latest
30 steps:
31 - uses: actions/checkout@v4
32 - run: npm install -g @github/spec-kit
33 - name: Audit ${{ matrix.service }}
34 env:
35 ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
36 run: |
37 cd services/${{ matrix.service }}
38 FEATURE=$(echo "$GITHUB_HEAD_REF" | sed 's/feature\/[A-Z0-9-]*-//')
39 if [ -d ".specify/features/$FEATURE" ]; then
40 specify audit --feature $FEATURE
41 fiPola detect-then-matrix ini menjaga biaya CI tetap proporsional dengan perubahan: PR yang hanya menyentuh satu service hanya memicu satu job audit. Di monorepo dengan banyak service, efisiensi ini sangat terasa di tagihan token maupun waktu tunggu.
17.8 CLAUDE.md Hierarki di Monorepo
Setiap service sebaiknya punya CLAUDE.md sendiri yang fokus pada konteks lokalnya, bukan satu file raksasa untuk semua. Contoh berikut adalah CLAUDE.md order-service yang menunjuk ke constitution root sekaligus menjelaskan tanggung jawab spesifiknya.
1# services/order-service/CLAUDE.md
2
3## Context
4This is the Order Service within Santekno Shop monorepo.
5Monorepo root: ../../
6Shared constitution: ../../.specify/constitution.md
7
8## This Service
9- Responsibility: Order lifecycle management (create, confirm, ship, deliver, cancel)
10- Team: @order-team (Andi, Budi, Citra)
11- Kafka topics produced: ORDER_CREATED, ORDER_CONFIRMED, ORDER_CANCELLED
12- Kafka topics consumed: PAYMENT_COMPLETED, SHIPPING_UPDATED
13- Database: PostgreSQL (pgx/v5)
14- Other services called: product-service (stock check), payment-service (initiate payment)
15
16## Service-Specific Patterns
17[Patterns khusus order-service yang tidak ada di global constitution]
18
19## Contracts
20- Produces: ../../.specify/contracts/order-cancelled-event.md
21- Consumes: ../../.specify/contracts/payment-completed-event.mdCLAUDE.md yang fokus per service ini membuat AI mendapat konteks yang padat dan relevan, bukan tenggelam dalam detail service lain. Referensi eksplisit ke constitution root dan daftar kontrak juga memastikan AI tahu batas tanggung jawab service saat menggenerate kode.
17.9 Shared Library Spec
Perubahan pada shared library berdampak ke semua service yang memakainya, jadi ia pun perlu di-spec. Perintah berikut membuat spec khusus untuk perubahan library domain-events.
1# Spec untuk library perubahan
2cd libs/domain-events
3specify feature --feature "add-review-events"
4
5# Spec di: libs/domain-events/.specify/features/add-review-events/
6# Plan akan mention: bumping library version, all consumers need to updateKarena plan-nya secara eksplisit menyebut “all consumers need to update”, tidak ada consumer yang tertinggal saat library naik versi. Memperlakukan library seperti service — dengan spec dan plan sendiri — adalah kunci menjaga monorepo tetap koheren.
17.10 Monorepo Tips & Gotchas
Tip 1: Root constitution = prinsip universal. Service-level constitution = service-specific rules.
Tip 2: Event contracts di .specify/contracts/ mencegah schema mismatch antar service.
Tip 3: Deploy order harus muncul di cross-service plan.
Gotcha 1: Jangan duplikasi constitution — service-level hanya untuk additions, tidak override root.
Gotcha 2: Shared library change bisa break banyak service — selalu spec dan plan library changes.
17.11 Ringkasan Sementara
Sampai titik ini, kita sudah melihat fondasi Spec Kit di monorepo: hierarki constitution (root ke service), cross-service feature spec, dan event contract di .specify/contracts/ sebagai penjaga konsistensi antar-service.
Bagian berikutnya masuk lebih dalam ke topik lanjutan — Go workspace, cross-service task dependency, deteksi breaking change, sampai dashboard monorepo — yang semuanya melengkapi fondasi di atas.
17.12 Go Workspace dan Spec Kit
Monorepo Go modern biasanya memakai go.work untuk mengikat banyak modul. Spec Kit perlu memahami struktur workspace ini agar bisa me-resolve import lintas-service dengan benar.
1# go.work
2go 1.22
3
4use (
5 ./services/order-service
6 ./services/product-service
7 ./services/notification-service
8 ./libs/domain-events
9)
10
11# Spec Kit dengan workspace awareness
12specify feature --workspace --service order-service
13
14# Spec Kit membaca go.work untuk:
15# - Tahu semua service yang ada
16# - Resolve cross-service imports
17# - Generate plan yang aware of shared library versionsDengan membaca go.work, Spec Kit bisa menghasilkan plan yang sadar akan versi shared library dan dependensi antar-modul. Ini penting agar rekomendasi implementasi tidak menabrak struktur workspace yang sebenarnya.
17.13 Cross-Service Task Dependencies
Fitur lintas-service butuh koordinasi di level task, bukan hanya plan. Dua berkas tasks berikut menunjukkan bagaimana task di satu service secara eksplisit menyatakan dependency dan urutan deploy terhadap service lain.
1# .specify/features/order-notification/tasks-order-service.md
2
3## Task 01: Implement Kafka Publisher untuk ORDER_CANCELLED (order-service)
4**Estimasi:** 45 menit
5**File:** services/order-service/internal/kafka/order_cancelled_publisher.go
6**Depends on:** notification-service Task 01 (consumer harus ready dulu untuk testing)
7
8---
9
10# .specify/features/order-notification/tasks-notification-service.md
11
12## Task 01: Implement ORDER_CANCELLED Consumer (notification-service)
13**Estimasi:** 60 menit
14**File:** services/notification-service/internal/consumer/order_cancelled_consumer.go
15**Deploy before:** order-service (consumer ready sebelum producer publish)Field Depends on dan Deploy before di level task inilah yang menjaga tiga hal sekaligus: urutan deployment, sekuens integration testing, dan backward-compatibility kontrak. Tanpa ini, koordinasi lintas-service mudah tercecer di kepala masing-masing developer.
17.14 Monorepo-Specific Spec Patterns
Ada beberapa pola spec yang khas monorepo dan jarang muncul di single-service. Pattern pertama, shared domain event, mendefinisikan AC terpisah untuk sisi producer dan consumer dalam satu spec.
1# .specify/features/add-review-event/spec.md
2# Feature ini menyentuh: product-service (producer), search-service (consumer)
3
4## User Stories
5Sebagai sistem, ketika review baru dibuat, event REVIEW_CREATED harus dipublikasikan
6agar search-service bisa update search index dengan rating terbaru.
7
8## Acceptance Criteria
9### Product Service (Producer)
10- AC1: Publish REVIEW_CREATED event setelah review tersimpan di DB
11- AC2: Event payload sesuai contract di .specify/contracts/review-created.md
12- AC3: Publish bersifat best-effort (tidak fail order jika Kafka down)
13
14### Search Service (Consumer)
15- AC4: Consume REVIEW_CREATED event dari topic product-events
16- AC5: Update Elasticsearch index dengan rating terbaru
17- AC6: Idempotent: processing event yang sama dua kali tidak create duplicateMemisahkan AC producer dan consumer dalam satu spec membuat kontrak antar-service jadi eksplisit dan dapat di-audit di kedua sisi. Pola kedua, library change spec, mengatur perubahan pada shared library dengan disiplin semantic versioning seperti berikut.
1# libs/domain-events/.specify/features/add-review-event-type/spec.md
2
3## Acceptance Criteria
4- AC1: Tambah ReviewCreatedEvent struct ke package domain-events
5- AC2: Backward compatible: tidak remove atau rename existing types
6- AC3: Version bump: v1.2.3 → v1.3.0 (minor version karena additive change)
7- AC4: Update go.mod di semua consumers setelah library releaseDua pola ini menegaskan prinsip yang sama dari sudut berbeda: perubahan yang menyeberangi batas service atau library harus punya AC yang menjaga backward-compatibility. Itulah yang membuat monorepo besar tetap bisa berevolusi tanpa ledakan regresi.
17.15 Detecting Cross-Service Breaking Changes
Breaking change pada event contract bisa merusak banyak consumer sekaligus. Perintah audit cross-service berikut mendeteksi perubahan berbahaya dan mengidentifikasi service mana saja yang terdampak.
1# Cek apakah spec change berdampak ke service lain
2specify audit --cross-service --feature add-review-event
3
4# Output:
5# Cross-Service Impact Analysis
6#
7# Changed: .specify/contracts/review-created.md
8#
9# Services yang menggunakan contract ini:
10# - search-service (consumer, .specify/features/*/spec.md references this)
11# - analytics-service (consumer, discovered via Kafka topic config)
12#
13# Breaking change detected?
14# YES: Field 'product_rating_after' type changed: float64 → int64 cents
15# This is a BREAKING change for all consumers
16#
17# Required actions:
18# 1. Version bump: REVIEW_CREATED_V2 (keep V1 for 3 months)
19# 2. Update plan untuk migration window
20# 3. Notify: @search-team, @analytics-teamAudit ini mengubah pertanyaan menakutkan “apakah perubahan ini aman?” menjadi laporan konkret berisi consumer terdampak dan langkah mitigasi. Deteksi dini seperti inilah yang mencegah satu perubahan skema menjatuhkan beberapa service di produksi sekaligus.
17.16 Monorepo Constitution: Bagian yang Sering Terlewat
Constitution monorepo harus mengatur hal-hal yang tidak relevan bagi single-service — terutama batas antar-service dan aturan komunikasi. Bagian constitution berikut memuat standar sinkron/asinkron, service boundary, dan deployment.
1# .specify/constitution.md — Monorepo Section
2
3## Inter-Service Communication Standards
4
5### Synchronous (REST/gRPC)
6- Timeout wajib: 5 detik untuk service-to-service call
7- Circuit breaker wajib dengan thresholds: 50% error rate, 10-second window
8- Service harus bisa berjalan tanpa dependen service UP (degraded mode)
9
10### Asynchronous (Kafka)
11- At-least-once delivery: consumer harus idempotent
12- Event schema versioning: additive changes okay, field removal/rename = new version
13- Retention minimal 7 hari untuk semua topics
14- Dead Letter Queue wajib untuk semua consumer
15
16### Shared Library
17- Semantic versioning wajib (semver.org)
18- Breaking changes: major version bump
19- Deprecation notice: minimal 1 sprint sebelum removal
20
21## Service Boundaries
22- Setiap service punya database sendiri (database per service)
23- TIDAK boleh query database service lain secara langsung
24- Data sharing hanya via API atau events
25- Circular dependency antar service dilarang keras
26
27## Deployment
28- Blue-green deployment untuk semua service
29- Consumer deploy SEBELUM producer (consumer-first deployment)
30- Rollback plan WAJIB untuk setiap breaking changeAturan seperti “database per service” dan “consumer-first deployment” adalah keputusan arsitektural yang mudah dilanggar di tengah tekanan deadline. Menuliskannya di constitution mengubahnya dari niat baik menjadi aturan yang bisa di-enforce lewat review dan CI.
17.17 Monorepo CI Matrix Strategy
Alternatif dari deteksi git-diff manual adalah memakai path filter yang deklaratif. Konfigurasi berikut memakai dorny/paths-filter untuk menjalankan audit hanya pada service yang path-nya berubah.
1# Efficient CI untuk monorepo: hanya audit service yang berubah
2
3jobs:
4 detect-changes:
5 runs-on: ubuntu-latest
6 outputs:
7 order: ${{ steps.changes.outputs.order }}
8 product: ${{ steps.changes.outputs.product }}
9 notification: ${{ steps.changes.outputs.notification }}
10 steps:
11 - uses: dorny/paths-filter@v3
12 id: changes
13 with:
14 filters: |
15 order:
16 - 'services/order-service/**'
17 - '.specify/features/**'
18 - '.specify/contracts/**'
19 product:
20 - 'services/product-service/**'
21 notification:
22 - 'services/notification-service/**'
23
24 audit-order:
25 needs: detect-changes
26 if: needs.detect-changes.outputs.order == 'true'
27 runs-on: ubuntu-latest
28 steps:
29 - uses: actions/checkout@v4
30 - run: |
31 cd services/order-service
32 specify audit --all --threshold 85
33
34 # Similar for product-service and notification-servicePerhatikan bahwa filter order-service juga memantau .specify/contracts/**: perubahan kontrak yang dikonsumsinya ikut memicu audit. Path filter deklaratif seperti ini lebih mudah dibaca dan dipelihara dibanding parsing git-diff manual di shell.
17.18 Monorepo Spec Dashboard
Untuk memantau kesehatan seluruh monorepo dalam sekali pandang, Spec Kit menyediakan dashboard tingkat repo. Perintah berikut menampilkan skor per service, isu terbuka, dan status cross-service.
1# Dashboard untuk seluruh monorepo
2specify dashboard --monorepo
3
4# Output:
5# Santekno Shop Monorepo — Spec Dashboard
6# =========================================
7#
8# Services: 3 | Features tracked: 24 | Constitution: v2.1
9#
10# Per-Service Status:
11#
12# order-service 96/100 8 features
13# product-service 89/100 10 features
14# notification-service 82/100 6 features ← needs attention
15#
16# Open Issues:
17# notification-service: 2 features below 85% threshold
18# - email-template: 78/100 (AC6 missing)
19# - push-notification: 81/100 (EC2 not covered)
20#
21# Cross-Service:
22# Event contracts: 3/3 validated
23# Circular dependency check: OK
24# Constitution compliance: 24/24 featuresDashboard ini langsung menyorot service yang butuh perhatian (notification-service di 82) beserta akar masalahnya (AC6 dan EC2). Bagi tech lead monorepo, view seperti ini menggantikan proses menanyai tiap tim satu per satu soal status kepatuhan spec.
17.19 Tips & Gotchas untuk Monorepo
Tip 1: Constitution versioning — tandai versi di constitution.md (# Version: 2.1) dan commit dengan tag. Breaking change ke constitution berarti major version bump.
Tip 2: Service isolation principle — setiap service punya CLAUDE.md, spec, dan plan sendiri. Jangan buat satu CLAUDE.md untuk semua service — terlalu panjang dan tidak fokus.
Tip 3: Event contract sebagai “API” antar service — .specify/contracts/ adalah OpenAPI spec-nya untuk komunikasi async. Perlakukan perubahan kontrak sama seperti breaking REST API.
Tip 4: Run cross-service audit secara berkala — jadwalkan audit lintas-service mingguan untuk menangkap inkonsistensi lebih dini.
1# Mingguan: cek konsistensi antar service
2specify audit --cross-service --allMenjalankan audit lintas-service secara terjadwal mengubah pemeriksaan konsistensi dari reaktif menjadi preventif. Selain tips di atas, ada beberapa jebakan yang perlu diwaspadai secara khusus di monorepo:
Gotcha 1: Constitution conflict saat banyak feature branch — jika 3 developer masing-masing update constitution.md di branch berbeda, akan muncul 3-way merge conflict. Solusinya: hanya tech lead yang update constitution, via dedicated branch.
Gotcha 2: Cross-service spec bisa membuat bottleneck — jika setiap fitur melibatkan multiple service dan butuh cross-service review, velocity bisa turun signifikan. Pertimbangkan async review untuk fitur low-risk.
Gotcha 3: Token cost naik linear dengan jumlah service — specify audit --all di monorepo dengan 5 service bisa menghabiskan 5x token dibanding single service. Anggarkan sesuai jumlah service.
Gotcha 4: Go workspace + Spec Kit masih evolving — dukungan go.work di Spec Kit masih berkembang. Untuk workspace kompleks, mungkin perlu skrip kustom tambahan.
17.20 Ringkasan
Spec Kit di monorepo bekerja dengan hierarki dua level: root constitution untuk prinsip yang berlaku universal, dan service-specific constitution (atau additions) untuk aturan khusus per service.
Cross-service feature specs di root .specify/features/ memungkinkan koordinasi antar service tanpa kehilangan isolation — setiap service tetap punya spec, plan, dan tasks sendiri. Event contracts di .specify/contracts/ adalah “API contract” untuk komunikasi async antar service; breaking change di kontrak harus diperlakukan sama seriusnya dengan breaking REST API. Dan CI strategy berbasis path-filtering memastikan hanya service yang berubah yang di-audit — efisien dari sisi biaya maupun waktu.
Di artikel berikutnya, kita fokus pada validasi implementasi terhadap spesifikasi sebagai proses yang berjalan terus-menerus — bukan hanya saat debugging, tapi sebagai bagian integral dari development workflow.