Lewati ke isi

Scola Workspace Governance

Catatan: Mulai dari scola-fe-v2/docs/AI Guidelines/AGENTIC_AI_APP_DEV_GUIDE.md untuk panduan agentic AI end-to-end. Dokumen ini menggunakan path server /home/scola/odoo. Untuk mode lokal, ganti root sesuai lokasi clone, namun aturan permission tetap sama.

📍 UPDATE 2026-01-19: Pengembangan dilakukan langsung di server /home/scola/odoo/

Repository Overview

Server-Based Development Environment

Pengembangan dilakukan langsung di server untuk testing instan:

/home/scola/odoo/
├── scola-fe-v2/                    # Vue.js Frontend (EDITABLE)
├── custom_addons_scola/gcgscola/   # Custom Scola Modules (EDITABLE)
├── custom_addons/                  # OpenEduCat Modules (REFERENCE)
├── odoo/                           # Odoo Core (READ-ONLY)
├── addons/                         # Odoo Standard Addons (READ-ONLY)
└── config/                         # Configuration files

Permission Matrix

Path Purpose Permission Notes
scola-fe-v2/ Vue.js Frontend EDITABLE Main frontend development
custom_addons_scola/gcgscola/ Custom Odoo Modules EDITABLE Scola extensions
custom_addons/openeducat_* OpenEduCat Base ⚠️ REFERENCE Extend via _inherit, don't modify
odoo/, addons/ Odoo Core READ-ONLY Never modify

Repository Policies

1. scola-fe-v2 (Frontend)

What can be changed: - Vue.js components, views, composables - Route definitions and navigation - API service layer (/src/services/) - Menu structure and RBAC guards - Styling and UI components - Frontend tests - Documentation in /docs/

Build/Test Gates:

npm install
npm run build
npm run lint
npm run test


2. scola-odoo-module (Custom Backend)

What can be changed: - Custom Odoo modules (scola_* directories) - Model definitions (extending base models) - Controllers (new API endpoints) - Security rules (ir.model.access.csv, record rules) - Data files (data/*.xml) - Menu actions - Documentation in /docs/

Extension Pattern:

# CORRECT: Extend base model via _inherit
class StudentExtension(models.Model):
    _inherit = 'op.student'
    custom_field = fields.Char('Custom Field')

# WRONG: Do not modify base model directly

Build/Test Gates:

# Verify module installation
python odoo-bin -c odoo.conf -i scola_core --stop-after-init


3. scola-be (Base - READ-ONLY)

⚠️ THIS REPOSITORY IS READ-ONLY

What can be done: - ✅ Read code for reference - ✅ Analyze dependencies and extension points - ✅ Document base functionality

What CANNOT be done: - ❌ Modify any files - ❌ Create branches - ❌ Submit PRs - ❌ Direct commits

If you need to change base behavior: 1. Create an extension in scola-odoo-module 2. Use _inherit to extend models 3. Override methods via Python inheritance 4. Add security rules in custom module


Change Propagation Flow

┌─────────────────┐
│   scola-be      │  ← READ-ONLY (OpenEduCat + Odoo base)
│  (base models)  │
└────────┬────────┘
         │ _inherit
         ▼
┌─────────────────┐
│ scola-odoo-     │  ← EDITABLE (custom extensions)
│ module          │
│ (custom models, │
│  controllers,   │
│  security)      │
└────────┬────────┘
         │ REST API
         ▼
┌─────────────────┐
│  scola-fe-v2    │  ← EDITABLE (Vue.js frontend)
│  (UI, routes,   │
│   services)     │
└─────────────────┘

Rules for Agentic AI Agents

General Rules

  1. Always check repository permission before making changes
  2. 1 Issue → 1 Branch → 1 PR (atomic work units)
  3. PR must reference Issue: Use Closes #ID in PR description
  4. No direct commits to main - always use feature branches
  5. Update documentation when changing functionality

Definition of Done

Every PR must satisfy: - [ ] Build passes (frontend: npm run build, backend: module installs) - [ ] Role/access checked (where relevant) - [ ] Docs updated (where relevant) - [ ] Evidence attached (screenshots/logs) - [ ] PR template fully completed

Blocked Issues

If blocked, comment in the Issue using prefix:

BLOCKED: [describe the blocker and what you need]

Branch Naming

# Frontend (scola-fe-v2)
feature/[issue-id]-[short-description]
fix/[issue-id]-[short-description]

# Backend (scola-odoo-module)
feature/[issue-id]-[short-description]
fix/[issue-id]-[short-description]

GitHub Project

Project: Scola – Finish Line (FE + Custom Odoo Modules) – 2026

Board Columns: - Backlog - New issues - Ready - Assigned and ready to work - In Progress - PR opened - Review - PR ready for review - Done - PR merged


Contact

  • Orchestrator/Lead: Manages project, triage, merges, gates
  • Agent FE: Owns frontend issues
  • Agent Odoo: Owns backend custom module issues
  • Agent QA: Owns testing and demo readiness

Server Development Quick Reference

Start Development

# Backend (Odoo) - Terminal 1
cd /home/scola/odoo
./odoo-bin -c config/scola-dev.conf

# Frontend (Vue.js) - Terminal 2
cd /home/scola/odoo/scola-fe-v2
npm run dev

Common Commands

# Update Odoo module
./odoo-bin -c config/scola-dev.conf -u scola_core --stop-after-init

# Lint frontend
cd scola-fe-v2 && npm run lint

# Build frontend
cd scola-fe-v2 && npm run build

# Database backup
pg_dump -U scola scola_dev > backup_$(date +%Y%m%d).sql

Safety Checklist

  • [ ] Check running processes before starting servers
  • [ ] Backup database before major changes
  • [ ] Never modify files in odoo/, addons/, or custom_addons/openeducat_*
  • [ ] Test changes before committing
  • [ ] Use feature branches for all changes
  • [ ] Jika push dengan [skip ci]: pastikan QC checklist di development-guide.md §10 sudah lulus seluruhnya

CI Strategy: Server-First vs Workflow CI

Karena pengembangan dilakukan langsung di server, ada dua jalur deployment:

Jalur Kapan CI Workflow Syarat
Server-first Perubahan dikembangkan & diuji di server dev Skip dengan [skip ci] QC checklist §10 development-guide.md lulus
Workflow CI Perubahan dari mesin lokal atau PR Jalan normal
Staging Sebelum ke produksi Wajib CI penuh Tidak boleh [skip ci]
Manual trigger Verifikasi ulang kapan saja workflow_dispatch

Aturan [skip ci]

  1. Tambahkan [skip ci] di commit message hanya setelah semua QC gate lolos di server.
  2. Tidak berlaku untuk staging — staging wajib melalui CI GitHub Actions penuh.
  3. pull_request tidak terpengaruh [skip ci] — CI tetap berjalan di PR.
  4. Jika ada keraguan, jangan pakai [skip ci] — biarkan CI berjalan sebagai safety net.
  5. Gunakan workflow_dispatch untuk trigger ulang CI secara manual kapan saja.

Last updated: 2026-04-13 (Server-first deployment flow added)