Sumber belajar

Prompt adopsi, contoh sintetis, glosarium Indonesia–Inggris, Product Requirements learning ladder, FAQ, dan rute belajar PAB–AEOS.

Gunakan sumber ini untuk belajar dan berdiskusi, bukan sebagai pengganti authority, project policy, Authoritative Requirements, atau artefak normatif. Semua contoh bersifat sintetis dan sengaja tidak membawa nama proyek, repository, data, target, credential, atau state operasional privat.

Contoh generik

Proyek katalog belajar sintetis

Description: Walkthrough generik dari goal dan baseline sampai closure, lengkap dengan authorization, verification, acceptance, dan residual risk.

Prompt awal adopsi

Adopsi PAB-AEOS dari repository canonical ke project ini. Mulai dengan audit read-only terhadap konteks, authority, Authoritative Requirements, capability, struktur, dan evidence project; gunakan profil serta opsi adopsi yang sesuai tanpa mengganti atau merusak sistem yang sudah ada.

Glosarium Indonesia–Inggris

kewenangan

English: authority

Definition: Hak yang sah untuk memutuskan atau mengizinkan tindakan pada scope tertentu.

kemampuan operasional

English: capability

Definition: Kemampuan nyata environment, alat, atau operator; capability tidak memberi authority.

bukti

English: evidence

Definition: Rekaman traceable yang mendukung atau membantah claim melalui source, method, revision, waktu, dan limitation.

tujuan

English: goal

Definition: Outcome terukur yang diinginkan dan menjadi arah mission.

keadaan dasar

English: baseline

Definition: Keadaan terverifikasi sekarang yang menjadi titik pembanding bagi goal.

kesenjangan

English: gap

Definition: Perbedaan material yang telah diverifikasi antara baseline dan goal.

misi

English: mission

Definition: Unit kerja berbatas yang menghubungkan goal, scope, authority, action, evidence, dan acceptance.

verifikasi

English: verification

Definition: Pemeriksaan bahwa claim dan acceptance criteria didukung evidence.

penerimaan

English: acceptance

Definition: Keputusan authority bahwa deliverable memenuhi kebutuhan dan residual risk dapat diterima.

penutupan

English: closure

Definition: Keputusan eksplisit setelah deliverable diterima, risiko dicatat, baseline diperbarui, dan knowledge dipelihara.

risiko residual

English: residual risk

Definition: Risiko yang tersisa setelah control dan harus diketahui oleh acceptance authority.

asal-usul bukti

English: provenance

Definition: Rantai yang menghubungkan evidence ke source, producer, revision, waktu, dan method.

kemandirian sesi

English: session independence

Definition: Kemampuan peserta berkualifikasi memulihkan state dan next decision tanpa chat historis.

gerbang rilis

English: release gate

Definition: Pemeriksaan authority, capability, target, revision, evidence, dan control sebelum action release.

Requirements glossary

persyaratan otoritatif

Term: authoritative-requirements

English: Authoritative Requirements

Definition: Sumber product atau outcome truth yang telah diterima dan menjadi referensi mission material; tidak menciptakan authority.

gerbang persyaratan produk

Term: product-requirements-gate

English: Product Requirements Gate

Definition: Kontrol PAB-AEOS 0.3 yang memastikan mission applicable terikat ke requirements source, exact baseline, dan stable Requirement IDs.

persyaratan produk

Term: product-requirements

English: PRODUCT requirements

Definition: Requirements Kind untuk generic-software yang menyatakan perilaku, kualitas, batas, dan invariant produk.

persyaratan hasil

Term: outcome-requirements

English: OUTCOME requirements

Definition: Requirements Kind untuk generic-knowledge-work yang menyatakan hasil yang harus benar tanpa memaksakan bentuk PRD software.

ID persyaratan

Term: requirement-id

English: Requirement ID

Definition: Identifier stabil seperti WEB-FR-001 yang menghubungkan mission, implementasi, test, dan evidence ke requirement tertentu.

baseline persyaratan

Term: requirements-baseline

English: requirements baseline

Definition: Digest SHA-256 canonical dari exact requirements source yang diikat mission untuk mencegah perubahan intent tanpa traceability.

traceability wajib

Term: required-traceability

English: REQUIRED traceability

Definition: Applicability untuk mission product/outcome-impacting yang wajib menyebut source, exact baseline, dan applicable Requirement IDs.

traceability tidak berlaku

Term: not-applicable-traceability

English: NOT_APPLICABLE traceability

Definition: Applicability untuk mission yang benar-benar tidak mengubah product/outcome contract; wajib memiliki alasan dan tidak boleh membawa trace fields kontradiktif.

Requirements learning

Beginner

Title: Beginner — mengapa requirements diperlukan
Text: Pelajari bahwa mission yang lulus test masih dapat menghasilkan produk yang salah bila product intent tidak jelas. Authoritative Requirements menjelaskan apa yang harus benar, sedangkan Authority Registry menjelaskan siapa yang berhak memutuskan.
Requirements path: /requirements/

Intermediate

Title: Intermediate — lifecycle dan traceability
Text: Pelajari lifecycle DRAFT sampai ACTIVE, stable Requirement IDs, exact SHA-256 baseline, serta perbedaan REQUIRED dan NOT_APPLICABLE pada mission traceability.
Requirements path: /requirements/

Professional

Title: Professional — change control dan assurance boundary
Text: Pelajari bagaimana requirements changes memerlukan authority yang sah, baseline baru, mission re-binding, serta mengapa AI atau passing tests tidak otomatis memberi requirements-change, merge, deploy, release, atau production authority.
Requirements path: /requirements/

Pertanyaan umum

Apakah PAB memberi izin untuk mengubah atau merilis sistem?

Answer: Tidak. PAB memberi advice dan assurance. Authorization harus datang dari authority yang sah dan terikat action, target, scope, batas, serta waktu.

Apakah Authoritative Requirements memberi izin eksekusi atau deployment?

Answer: Tidak. Requirements menjelaskan apa yang harus benar pada product atau outcome. Execution, merge, deploy, release, production, secret access, dan requirements-change authority tetap membutuhkan authority terpisah.

Apakah AEOS adalah model AI atau platform deployment?

Answer: Bukan. AEOS adalah operating system rekayasa yang merutekan state dan menerapkan contract; project adapter menghubungkannya ke tool dan control lokal.

Apakah capability VERIFIED berarti tindakan boleh dijalankan?

Answer: Tidak. Capability menjawab mampu; authority menjawab boleh. Tindakan material memerlukan keduanya secara terpisah.

Apakah bootstrap READY berarti misi atau deployment sudah diotorisasi?

Answer: Tidak. READY hanya menyatakan prerequisite bootstrap yang dideklarasikan cukup. Bootstrap bersifat read-only dan tidak menjalankan misi atau release.

Apakah test lokal yang lulus membuktikan production tersedia?

Answer: Tidak. Test lokal mendukung claim pada source, revision, environment, dan method yang diuji. Production memerlukan runtime evidence pada target yang tepat.

Apakah chat dapat menjadi authority atau evidence final?

Answer: Chat dapat membawa intent atau historical context, tetapi keputusan dan evidence material harus dipelihara dalam artefak efektif yang traceable.

Bolehkah adopter memperkuat control?

Answer: Ya. Adapter atau policy lokal boleh memperkuat control, tetapi tidak boleh diam-diam melemahkan konstitusi atau mengubah precedence.

Kapan pekerjaan harus berhenti?

Answer: Berhenti saat authority ambigu, evidence material stale atau contradicted, capability tidak cukup, scope bergeser, path keluar boundary, atau tindakan irreversible belum diotorisasi.

Apakah materi publik ini adalah spesifikasi normatif?

Answer: Tidak. Materi ini adalah penjelasan pendidikan. Untuk operasi, gunakan versi artefak normatif yang efektif pada scope adopter.

Apakah status Candidate berarti production-ready atau assured?

Answer: Tidak. Candidate berarti mekanisme memiliki evidence internal tetapi cross-project evidence belum lengkap. Production readiness dan assurance memerlukan gate serta evidence terpisah.

Apakah adopsi PAB–AEOS harus mengaktifkan semua opsi?

Answer: Tidak. Profil dan dokumen single-actor, standing authority, skill routing, serta kolaborasi AI bersifat tambahan dan opt-in. Adopter memilih serta meratifikasi hanya yang sesuai dengan konteksnya.

Tautan terkait

Pelajari Authoritative Requirements

Lihat kerangka dan diagram PAB–AEOS

Glosarium lengkap

Ketentuan penggunaan pendidikan

Evidence dan roadmap

Mulai belajar

Walkthrough proyek sintetis

Contoh sintetis: filter katalog belajar

Id: generic-learning-catalog

Classification: synthetic

Purpose: Menunjukkan lifecycle PAB–AEOS lengkap pada proyek rekaan tanpa organisasi, repository, environment, data, atau tool nyata.

Disclaimer: Semua nama, scenario, result, actor role, revision, dan evidence dalam contoh ini rekaan untuk pendidikan. Contoh ini bukan production claim, authorization, conformance decision, atau case study proyek nyata.

Project profile

Type

small static software project

Risk

low, non-production learning exercise

Data

synthetic catalog entries only

Critical path

learner can apply a topic filter and see matching entries

Capabilities

Id: repository-read
State: VERIFIED

Id: repository-write
State: VERIFIED

Id: local-test
State: VERIFIED

Id: deployment
State: UNAVAILABLE

Penugasan fungsi keputusan

Function: recommendation
Actor: Penasihat rekaan

Function: authorization
Actor: Pemilik produk rekaan

Function: execution
Actor: Implementer rekaan

Function: verification
Actor: Reviewer rekaan

Function: acceptance
Actor: Pemilik hasil rekaan

Function: closure
Actor: Pemilik produk rekaan

Lifecycle walkthrough

Id: goal
State: CANDIDATE
Record: Pengguna dapat memilih satu topik dan hanya melihat entri katalog sintetis yang cocok.
Evidence: Goal statement dengan satu observable outcome.

Id: baseline
State: CANDIDATE
Record: Pada revision contoh R0, tiga entri selalu terlihat setelah topik dipilih.
Evidence: Tiga scenario awal: topik tata kelola, evidence, dan topik tanpa hasil; seluruhnya gagal terhadap expected filtering.

Id: gap
State: CANDIDATE
Record: Filter belum menggunakan topik yang dipilih untuk menentukan entri yang ditampilkan.
Evidence: Perbandingan literal antara expected result dan actual result pada ketiga scenario.

Id: mission
State: CANDIDATE
Record: Ubah hanya logic filter dan test fixture sintetis. Dilarang mengubah account, network, analytics, hosting, atau data source. Acceptance memerlukan tiga scenario lulus dan no-regression pada tampilan semua topik.
Evidence: Mission contract dengan deliverable, scope, allowed/forbidden actions, acceptance criteria, required evidence, stop conditions, dan context references.

Id: authorization
State: AUTHORIZED
Record: Pemilik produk rekaan mengotorisasi source edit dan local test hanya untuk mission serta revision R0. Commit, merge, dan deploy tidak termasuk.
Evidence: Authorization record mengikat actor, action categories, target, scope, constraints, effective time, dan completion condition.

Id: execution
State: IN_PROGRESS
Record: Implementer rekaan menambahkan failing scenario terlebih dahulu, lalu memperbaiki predicate filter pada scope yang diizinkan.
Evidence: Red test result, bounded diff summary, dan green test result pada revision contoh R1.

Id: verification
State: VERIFYING
Record: Reviewer rekaan menjalankan ulang tiga scenario dan no-regression check pada revision R1.
Evidence: Empat hasil verifikasi fresh pada revision R1: tiga filter scenario dan satu all-topics scenario lulus.

Id: awaiting-acceptance
State: AWAITING_ACCEPTANCE
Record: Reviewer rekaan mengirim acceptance request kepada pemilik hasil rekaan dengan revision R1, peta acceptance criteria, verification results, limitation, dan residual risk; misi lalu menunggu keputusan eksplisit.
Evidence: Acceptance request record mencatat pengirim, penerima, revision R1, evidence package, timestamp, dan status pending; waiting-state record menunjukkan belum ada acceptance decision.
Wait condition: Tetap AWAITING_ACCEPTANCE dan jangan memulai baseline update, closure, atau release sampai acceptance authority menerima, meminta revisi, atau menolak deliverable.

Id: acceptance
State: ACCEPTED
Record: Pemilik hasil rekaan menerima deliverable karena seluruh acceptance criteria didukung evidence dan residual risk dipahami.
Evidence: Acceptance decision yang menyebut revision R1, evidence package, limitation, dan residual risk.

Id: baseline-update
State: ACCEPTED
Record: Baseline baru menyatakan filter bekerja pada empat scenario lokal di revision R1; production behavior dan accessibility manual belum dinilai.
Evidence: Operational State dan baseline record yang diperbarui tanpa memperluas claim.

Id: closure
State: CLOSED
Record: Closure authority menutup mission setelah acceptance, baseline update, knowledge preservation, dan pencatatan residual risk. Release tetap tidak dijalankan.
Evidence: Closure record dan next decision terpisah: apakah perlu accessibility review sebelum release planning.

Risiko residual

Verification hanya menggunakan fixture dan environment lokal sintetis.
Keyboard dan screen-reader behavior belum diuji secara manual.
Tidak ada runtime atau production evidence karena deployment tidak tersedia dan tidak diotorisasi.

Pertanyaan belajar

Mengapa local-test capability tidak mengotorisasi commit atau deploy?
Evidence mana yang mendukung baseline R1, dan claim apa yang tetap tidak didukung?
Mengapa verification, acceptance, dan closure dicatat sebagai fungsi terpisah?
Decision apa yang diperlukan sebelum memasuki release planning?

Document IDs

PAB-CONSTITUTION
AEOS-CORE
AEOS-AUTHORITY
AEOS-CAPABILITY-CONTEXT
AEOS-MISSION
AEOS-EVIDENCE
AEOS-KNOWLEDGE
AEOS-RELEASE-GOVERNANCE