Εκπαίδευση developers CodeHero — Autonomous Development Framework (ADF)

Αρχείο γνώσης του Spec Builder: CODEHERO_PLANNING_GUIDE.md

Έκδοση 1.10 · Οκτώβριος 2026 · Για CodeHero PRO 5.0.2 και νεότερο

Αυτό είναι το εκπαιδευτικό πρόγραμμα για developers που θα σχεδιάζουν, θα ρυθμίζουν και θα λειτουργούν projects στο CodeHero. Διδάσκει το Autonomous Development Framework (ADF): τη μέθοδο που υλοποιεί το CodeHero, κατά την οποία AI agents χτίζουν, ελέγχουν και τεκμηριώνουν ένα προϊόν από μια προδιαγραφή, ενώ οι άνθρωποι δίνουν μόνο ό,τι δεν μπορεί να δώσει κανείς άλλος — την επιχειρησιακή αλήθεια, τα διαπιστευτήρια και τις εγκρίσεις.

Το πρωτότυπο του προγράμματος είναι γραμμένο στα αγγλικά ώστε να μπορεί να μοιραστεί με οποιαδήποτε ομάδα· αυτή είναι η ελληνική του έκδοση. Οι εκπαιδευόμενοι μπορούν να μιλούν στην πλατφόρμα ελληνικά ή αγγλικά· το CodeHero απαντά στη γλώσσα του χρήστη.

---

Πώς να χρησιμοποιήσετε αυτό το πρόγραμμα

Σε ποιους απευθύνεται. Σε developers, αναλυτές και τεχνικούς project managers που θα:

1. αντλούν απαιτήσεις από έναν πελάτη και τις μετατρέπουν σε πακέτο προδιαγραφής·
2. σχεδιάζουν ένα project στο CodeHero (tickets, ρόλοι, providers, ρυθμίσεις εκτέλεσης)·
3. λειτουργούν την εκτέλεση (διαβάζουν αναφορές, απαντούν σε ερωτήσεις, ξεμπλοκάρουν tickets, επαληθεύουν αποτελέσματα)·
4. προσαρμόζουν το ίδιο το framework επεξεργαζόμενοι το global context και τα project contexts.

Προαπαιτούμενα. Βασικές γνώσεις web development (HTTP, HTML, μια backend γλώσσα, SQL). Μια λειτουργική εγκατάσταση CodeHero PRO με τουλάχιστον δύο ενεργούς AI providers (έναν με δυνατότητα vision). Διαβάστε πρώτα τα κεφάλαια 2, 6, 8, 9, 11, 13, 14 και 15 του User Guide — το πρόγραμμα θεωρεί ότι γνωρίζετε το UI.

Δομή. Οκτώ ενότητες, με τη σειρά που γίνεται η δουλειά στην πράξη. Κάθε ενότητα τελειώνει με Ασκήσεις· η Ενότητα 8 είναι τελική εργασία (capstone) με κλίμακα αξιολόγησης. Προτεινόμενος ρυθμός: μία ενότητα ανά μισή ημέρα, η τελική εργασία την πέμπτη ημέρα.

Αρχεία στα οποία αναφέρεται το πρόγραμμα. Όλα τα paths είναι σχετικά με το δέντρο πηγαίου κώδικα του CodeHero (/home/claude/codehero/ σε μηχάνημα ανάπτυξης) ή με το εγκατεστημένο δέντρο (/opt/codehero/ και /etc/codehero/ σε server).

Κρατήστε αυτά τα αρχεία ανοιχτά όσο μελετάτε. Το πρόγραμμα τα εξηγεί· δεν τα αντικαθιστά.

Παρουσιάσεις. Ο ιστότοπος περιέχει παρουσιάσεις με σημειώσεις ομιλητή στο presentations/. Η πρώτη, The Domain Expert's Software Factory, αφηγείται την ιστορία αυτού του προγράμματος σε ανθρώπους της επιχείρησης χωρίς τεχνικό υπόβαθρο (συνέντευξη → έγκριση → κατασκευή και επαλήθευση → παράδοση, με το παράδειγμα RepairFlow των Ενοτήτων 2–7). Χρησιμοποιήστε την για να ανοίξετε ένα workshop με τον πελάτη ή για να ενημερώσετε τους ειδικούς του αντικειμένου από τους οποίους θα πάρετε συνέντευξη· το υλικό για developers μένει εδώ.

---

ΜΕΡΟΣ I — ΘΕΜΕΛΙΑ

Ενότητα 1 — Το framework: τι είναι το ADF και πώς το υλοποιεί το CodeHero

1.1 Ο ορισμός σε μία πρόταση

Το CodeHero είναι πλήρης υλοποίηση αυτής της ιδέας: μια πλατφόρμα (web UI, daemon, agent, εργαλεία, βάση δεδομένων, containers) συν μια γραπτή μέθοδος (το global context, ο οδηγός του Spec Builder, ο planner). Αυτό το πρόγραμμα διδάσκει τη μέθοδο· το User Guide διδάσκει την πλατφόρμα.

1.2 Γιατί χρειάζεται framework

Δώστε μια εργασία σε ένα ισχυρό μοντέλο και θα γράψει κώδικα. Αυτό δεν είναι το πρόβλημα. Τα προβλήματα εμφανίζονται τη δεύτερη ώρα:

• μαντεύει έναν επιχειρησιακό κανόνα (μια έκπτωση, ένα δικαίωμα, μια προθεσμία) και χτίζει με σιγουριά το λάθος προϊόν·
• ισχυρίζεται επιτυχία («τώρα θα πρέπει να δουλεύει») χωρίς να φορτώσει τη σελίδα·
• χάνει τη μνήμη του όταν γεμίσει το context window, και επαναλαμβάνει ή αντιφάσκει με προηγούμενη δουλειά·
• χαλάει κάτι που δούλευε ενώ διορθώνει κάτι άλλο·
• αποδυναμώνει μια προστασία (απενεργοποιεί validation, εισάγει χειροκίνητα μια γραμμή) για να περάσει ένα test·
• δύο agents που δουλεύουν ταυτόχρονα επεξεργάζονται το ίδιο αρχείο και καταστρέφουν ο ένας τη δουλειά του άλλου.

Κάθε κανόνας του ADF υπάρχει επειδή κάποιο από αυτά συνέβη σε πραγματική εκτέλεση. Το framework δεν είναι θεωρία· είναι το συσσωρευμένο σύνολο προστατευτικών κανόνων από παραδόσεις σε παραγωγή. Όταν αργότερα προσαρμόσετε τα contexts (Ενότητα 6), θυμηθείτε το: αλλάξτε έναν κανόνα μόνο όταν ξέρετε ποια αποτυχία αποτρέπει.

1.3 Οι δώδεκα αρχές

Αυτές είναι οι αρχές πίσω από το global context (config/global-context.md). Μάθετέ τες με το όνομά τους· το υπόλοιπο πρόγραμμα αναφέρεται σε αυτές.

Ένα χρήσιμο νοητικό τεστ όταν αξιολογείτε ένα πλάνο, μια αλλαγή context ή ένα ticket: ποια αρχή εξυπηρετεί αυτό, και ποια θέτει σε κίνδυνο;

1.4 Η ροή: από τη συζήτηση με τον πελάτη στο επαληθευμένο λογισμικό

 CLIENT (domain expert)
      │  interview: ask up to three related business questions in one message, one for a difficult choice;
      │  reuse supplied answers and show a first picture early · four statuses
      ▼
 SPEC BUILDER  (claude.ai / ChatGPT project + CODEHERO_PLANNING_GUIDE.md)
      │  specification package: header + codehero_environment + run settings
      │  + registers (requirements, decisions, dependencies) + ticket plan
      ▼
 PLAN WITH AI  (in-app planner, config/assistant-planner.md)
      │  writes the specification with the user or imports the package,
      │  shows preview → operator confirms → creates project + ONE [PLAN] ticket
      ▼
 PLANNING TICKET  ([PLAN] … in PLAN MODE, guides/planning.md, on the real installation)
      │  baseline → requirements → contracts → dry run → review rounds → peer check
      │  → assigns providers → creates the FIRST PHASE of tickets (last one: [REPLAN])
      ▼

 DAEMON + AGENT  (codehero-daemon → HeroAgent or CLI provider, per ticket)
      │  global context + project context + ticket → build → verify → report
      │  SPEC FILES (.specs/) + KNOWLEDGE BASE (graph) + git snapshots
      ▼
 VERIFY / FIX / REPLAN tickets  (VERIFY on another provider family; role + think per ticket kind, §4.4)
      │
      ▼
 END OF THE LINE  ([SECURITY] senior+pro and [PERFORMANCE], each with its [VERIFY] of the other family;
      │  the final [REPLAN]: docs/acceptance.md + docs/handover.md, restore drill on record, [VERIFY] final acceptance)
      │
      ▼
 HANDOFF REPORT → operator → client   (works+evidence · waiting on you · decided for you · open)

Το τέλος της γραμμής παραγωγής (4.65.1–4.65.2). Σκεφτείτε ένα εργοστάσιο αυτοκινήτων: κάθε σταθμός ελέγχει τη δική του δουλειά, ένας διαφορετικός επιθεωρητής υπογράφει κάθε παράδοση, και πριν το αυτοκίνητο φύγει από τη γραμμή περνά το crash test και το δυναμόμετρο· μετά την επιθεώρηση πριν την παράδοση, τα κλειδιά και το εγχειρίδιο. Στο CodeHero η τελευταία φάση περιέχει τον έλεγχο [SECURITY] (δύο διαφορετικά senior μοντέλα σε pro, κάθε κατηγορία ελεγμένη ενεργά, τοπικά από προεπιλογή) και τον έλεγχο [PERFORMANCE] (πρώτα μετριέται η ταχύτητα του ίδιου του server, φορτώνεται ο όγκος δεδομένων της προδιαγραφής), καθένας επαναλαμβανόμενος από ένα [VERIFY] της άλλης οικογένειας providers· το τελικό [REPLAN] γράφει το docs/acceptance.md (κάθε απαίτηση με την απόδειξή της) και το docs/handover.md (εγκατάσταση, το βήμα του πρώτου διαχειριστή, backups και η άσκηση επαναφοράς, αναβάθμιση, logs, βοήθεια ανά ρόλο) στη γλώσσα του πελάτη, και ένα πραγματικό project παίρνει ένα [VERIFY] final acceptance που διαβάζει και τα δύο απέναντι στο πραγματικό προϊόν. Ένα ticket [RELEASE] παραδίδει μια υποψήφια έκδοση (candidate)· το [REPLAN] που ακολουθεί την αποδέχεται μετά την πλήρη εκτέλεση της φάσης. Η περιγραφή του ticket είναι το φύλλο οδηγιών εργασίας του σταθμού: ο planner γράφει μέσα της ό,τι αλλιώς θα έπρεπε να ψάξει ο agent.

Τρεις «εγκέφαλοι» συμμετέχουν, και έχει σημασία με ποιον μιλάτε:

Ο Spec Builder βρίσκεται σκόπιμα έξω από την πλατφόρμα: χρειάζεται μια μακριά, ήρεμη συζήτηση με έναν άνθρωπο της επιχείρησης, ανέβασμα αρχείων και καμία πρόσβαση σε server. Οι άλλοι δύο ζουν μέσα στο CodeHero επειδή χρειάζονται τα πραγματικά στοιχεία της εγκατάστασης (ενεργούς providers, ports, containers).

1.5 Ο μηχανισμός (όσο χρειάζεται για να τον κατανοείτε)

Δεν χρειάζεται να διαβάσετε τον κώδικα για να λειτουργήσετε το CodeHero, αλλά πρέπει να ξέρετε τι τρέχει πού, επειδή κάθε ερώτηση της Ενότητας 5 («γιατί σταμάτησε;») καταλήγει σε ένα από αυτά τα μέρη.

Τα ports 9453 και 9867 είναι οι προεπιλογές· οι πραγματικές τιμές έρχονται από το /etc/codehero/system.conf (ADMIN_PORT, PROJECTS_PORT) και αντικαθίστανται στο context ως {ADMIN_PORT} και {PROJECTS_PORT}.

1.6 Τα επίπεδα οδηγιών

Όταν τρέχει ένα ticket, το system prompt του agent συντίθεται από επίπεδα, με αυτή τη σειρά (δείτε το build_project_context_file() στον daemon):

1. === CURRENT WORKING PROJECT === — id project, όνομα, id ticket· η σφραγίδα απομόνωσης («pass project_id=<id> to every codehero_* tool»).
2. Ένα στιγμιότυπο του knowledge graph — οι πιο σχετικοί κόμβοι της knowledge base του project.
3. Οι εγκατεστημένες βασικές οδηγίες, φορτωμένες από την αρχή σε κάθε εκτέλεση.
4. Οι εγκατεστημένες ενότητες stack που επιλέγονται από το project_stack και τον ρόλο του ticket, φορτωμένες από την αρχή σε κάθε εκτέλεση.
5. === PROJECT DESCRIPTION === και === PROJECT INFO === — η περιγραφή και το ελεύθερο πεδίο «additional notes» του project.
6. === RUNTIME ENVIRONMENT === — οι καρφωμένες εκδόσεις runtime («already installed — do NOT reinstall»).
7. === SERVER PORTS === — το συγκεκριμένο preview URL.
8. === PROJECT SEARCH TOOLS === — μόνο όταν το Codebase Map και/ή η σημασιολογική αναζήτηση είναι ενεργά για το project: ποιο εργαλείο απαντά σε ποια ερώτηση (ορισμοί και καλούντες → ο χάρτης· ερωτήσεις με βάση το νόημα → σημασιολογική αναζήτηση· κείμενο → Grep).
9. === PROJECT SERVICES === — βάσεις δεδομένων, caches και web apps με localhost:<port> και διαπιστευτήρια («already installed and running»).
10. === PROJECT SECRETS === — τα ονόματα (ποτέ οι τιμές) των secrets του project και πώς χρησιμοποιούνται μέσω path.
11. Κανόνες εκτέλεσης σε container και ο οδηγός deploy εφαρμογών σε container (μόνο για projects σε container).
12. Υλικό smart-context — χάρτης του project, προηγούμενες περιλήψεις εξαγωγής, πρόσφατο ιστορικό.

Έπειτα το prompt του user turn προσθέτει: paths του project, το block της βάσης δεδομένων, το δικό του context του ticket, την αλυσίδα γονικών tickets, τον τίτλο και την περιγραφή του ticket, τα επιτρεπόμενα paths εγγραφής και το συμβόλαιο ολοκλήρωσης («end your final message with TASK COMPLETED: <summary>»).

Τρεις συνέπειες που θα χρησιμοποιείτε συνεχώς:

• Από την 4.66.2, ο εγκατεστημένος πυρήνας και οι ενότητες stack που επιλέγονται από το project_stack φορτώνονται σε κάθε εκτέλεση· δεν αντιγράφονται ποτέ μέσα σε ένα project. Τα global_context, project_context και context περιέχουν μόνο τις προσθήκες που ζήτησε ρητά ο χρήστης, με τα δικά του λόγια. Μη βάζετε σε αυτά τα πεδία τον πυρήνα, μια ενότητα stack, έναν οδηγό, ένα template, μια αυτόματα παραγόμενη ανάλυση project ή την προδιαγραφή. Η προδιαγραφή ανήκει στο planning ticket.
• Τα πεδία φτάνουν στους agents μόνο όταν το additional_context_enabled είναι ενεργό. Τα νέα projects ξεκινούν ενεργά· τα projects που υπήρχαν κατά την αναβάθμιση 4.66.2 ξεκινούν ανενεργά. Τα overrides εφαρμόζονται πάνω από τις προεπιλογές της πλατφόρμας, με σειρά global < app < notes.
• Πριν καθαρίσετε παλιό περιεχόμενο ή ενεργοποιήσετε overrides, διαβάστε τα υπάρχοντα πεδία, ξεχωρίστε τα εγκατεστημένα αντίγραφα από τις προσθήκες του πελάτη, δείξτε ακριβώς τι θα αλλάξει και πάρτε την επιβεβαίωση του χρήστη. Το clear_context_fields=true καθαρίζει το global και το app context σύμφωνα με το schema του εργαλείου· μην υποθέτετε ότι διατηρεί κείμενο του πελάτη ή ότι καθαρίζει τα notes. Διατηρήστε τις επιβεβαιωμένες προσθήκες του πελάτη. Δεν υπάρχει ενέργεια ανανέωσης του global context. Το codehero_get_context_defaults είναι μόνο για ανάγνωση· μην αντιγράφετε ποτέ το αποτέλεσμά του μέσα σε ένα project.

1.7 Γλωσσάρι που πρέπει να ξέρετε πριν την Ενότητα 2

Ασκήσεις — Ενότητα 1

1. Ανοίξτε το config/global-context.md. Για καθεμία από τις δώδεκα αρχές, βρείτε την ακριβή ενότητα και αντιγράψτε μία πρόταση που τη διατυπώνει. (Θα χρειαστείτε αυτές τις παραπομπές στην Ενότητα 6.)
2. Διαβάστε τον πίνακα γλωσσαρίου στην §0 του global context. Εξηγήστε με δικά σας λόγια τη διαφορά ανάμεσα στο SPEC FILE και στη KNOWLEDGE BASE, και γιατί το framework κρατά και τα δύο.
3. Στην εκπαιδευτική σας εγκατάσταση, ανοίξτε τα Settings και καταγράψτε τους ενεργούς providers. Σημειώστε ποιοι έχουν vision. Κρατήστε τη λίστα ως χρονολογημένο αρχείο άσκησης. Κάθε πραγματικό πλάνο και κάθε ανάθεση provider ανανεώνει το codehero_get_providers_info· το στιγμιότυπο της άσκησης δεν είναι τρέχουσα πηγή αλήθειας.
4. Στο log του daemon (journalctl -u codehero-daemon -f) παρακολουθήστε ένα ticket να τρέχει από την αρχή ως το τέλος. Καταγράψτε τη σειρά των καταστάσεων που παρατηρήσατε.

---

ΜΕΡΟΣ II — ΑΝΤΛΗΣΗ ΓΝΩΣΗΣ ΑΠΟ ΤΟΝ ΠΕΛΑΤΗ

Ενότητα 2 — Η συνέντευξη του Spec Builder και το πακέτο προδιαγραφής

2.1 Το πρόβλημα που λύνει αυτή η ενότητα

Τα πιο ακριβά λάθη στο λογισμικό γίνονται πριν από την πρώτη γραμμή κώδικα: μια παρεξηγημένη διαδικασία, ένας κανόνας που δεν ειπώθηκε, μια επιθυμία που εκλήφθηκε ως δυνατότητα. Στο ADF η κατασκευή είναι αυτόνομη, οπότε δεν υπάρχει developer μέσα στον βρόχο για να προσέξει μια παρανόηση στη μέση του δρόμου. Ό,τι θα χρειαστούν οι agents πρέπει να αντληθεί από τον πελάτη πριν την εκτέλεση, σε μορφή που μπορούν να χρησιμοποιήσουν οι agents.

Αυτό κάνει ο Spec Builder. Δεν είναι φόρμα· είναι ένας συνεντευκτής με μέθοδο, και η δουλειά του developer είναι να τον χειριστεί σωστά, να εξετάσει κριτικά ό,τι παράγει και να ξέρει πότε έχει τελειώσει.

2.2 Η ρύθμισή του

1. Δημιουργήστε ένα project στο claude.ai (ή ένα ChatGPT project). Ανεβάστε το docs/CODEHERO_PLANNING_GUIDE.md ως γνώση του project.
2. Ορίστε την οδηγία του project ακριβώς σε: "You are the CodeHero Spec Builder. Follow the file CODEHERO_PLANNING_GUIDE.md exactly."
3. Ξεκινήστε τη συζήτηση με το υλικό του πελάτη (spreadsheets, screenshots, το τρέχον εγχειρίδιο) ήδη ανεβασμένο, ώστε ο assistant να το διαβάσει πριν ρωτήσει οτιδήποτε.

Ποιος κάθεται στο πληκτρολόγιο; Δύο τρόποι εργασίας είναι συνηθισμένοι:

• Πληκτρολογεί ο πελάτης. Ο Spec Builder γράφτηκε για έναν ειδικό του αντικειμένου χωρίς τεχνικό υπόβαθρο: ρωτά έως τρεις σχετικές επιχειρησιακές ερωτήσεις σε ένα μήνυμα, μία για μια δύσκολη επιλογή· επαναχρησιμοποιεί τις απαντήσεις που έχουν δοθεί και δείχνει νωρίς μια πρώτη εικόνα· χωρίς ορολογία, με προτεινόμενη απάντηση όποτε έχει βάση για μία. Εσείς εξετάζετε το transcript και το πακέτο μετά.
• Πληκτρολογείτε εσείς, με τον πελάτη δίπλα σας (ή σε κλήση). Πιο γρήγορο για μικρά εργαλεία· μπορείτε να αναδιατυπώσετε την ερώτηση του assistant με τα λόγια του πελάτη και να την κρατήσετε στον σωστό δρόμο. Πρέπει να αντισταθείτε στον πειρασμό να απαντήσετε εσείς σε επιχειρησιακές ερωτήσεις.

Σε κάθε περίπτωση, ο developer δεν επινοεί ποτέ επιχειρησιακό γεγονός. Αυτός ο κανόνας σας δεσμεύει ακριβώς όπως δεσμεύει τους agents (P3, P10).

2.3 Οι τέσσερις καταστάσεις — η ραχοκοκαλιά όλης της μεθόδου

Κάθε απαίτηση και κάθε απόφαση στο πακέτο φέρει μία κατάσταση και μία προέλευση:

Η προέλευση είναι user, document ή agent. Μια απαίτηση που πρότεινε ο assistant και ενέκρινε ο πελάτης είναι Confirmed / agent. Η στήλη προέλευσης είναι αυτή που επιτρέπει στον πελάτη να ελέγξει αργότερα «τι ζήτησα εγώ, και τι προσθέσατε εσείς;».

Δύο κανόνες κάνουν τις καταστάσεις έντιμες:

• Το «δεν ξέρω» είναι απάντηση. Ένα τεχνικό κενό συμπληρώνεται σιωπηλά ως Technical. Ένα επιχειρησιακό κενό γίνεται Assumed, με μία πρόταση που λέει τι υποτέθηκε.
• Τα κρίσιμα στοιχεία δεν υποτίθενται ποτέ σιωπηλά. Οτιδήποτε καθορίζει χρήματα, εγκρίσεις, δικαιώματα διαγραφής, νομικές υποχρεώσεις ή υποχρεώσεις συμμόρφωσης, ή ασφάλεια, μένει Open και ορατό σε κάθε σύνοψη μέχρι να το επιβεβαιώσει ο πελάτης — ακόμη κι όταν ο πελάτης θέλει να τελειώσει γρήγορα.

Θα δείτε την ίδια διάκριση ξανά κατά την εκτέλεση: το SAFE DEFAULT του agent (P5) είναι ακριβώς ένα στοιχείο Assumed επιλεγμένο έτσι ώστε να μην μπορεί να βλάψει κανέναν, και οι CRITICAL ερωτήσεις σταματούν το ticket αντί να πάρουν προεπιλογή.

2.4 Η συνέντευξη, στάδιο προς στάδιο

Το Μέρος 2 του Planning Guide είναι λίστα ελέγχου κάλυψης, όχι σενάριο. Ο assistant ρωτά με τη σειρά που κάνει φυσική η συζήτηση, παραλείπει ό,τι απαντά ήδη ένα έγγραφο και προσαρμόζει τη διατύπωση στον κλάδο. Ως developer, ελέγχετε την κάλυψη στο τέλος: πήρε κάθε στάδιο απάντηση ή συνειδητή προεπιλογή;

Ο Spec Builder 1.28 στοχεύει περίπου σε 6–8 επιχειρησιακές αποφάσεις για μικρό scope, 12–18 για μεσαίο και 20–30 για μεγάλη δουλειά. Αυτοί είναι στόχοι, όχι ποσοστώσεις ούτε άδεια να μείνει ανεπίλυτη μια κρίσιμη απόφαση.

Προσέξτε τα δύο υποχρεωτικά σημεία ελέγχου. Το Στάδιο C έρχεται πριν από οποιαδήποτε απόφαση τεχνολογίας, επειδή οι περιορισμοί — όχι το αρχέτυπο — καθορίζουν το stack (Ενότητα 3). Το Στάδιο P έρχεται πριν από την κλίμακα, το brand και την ασφάλεια, επειδή μια παρανόηση που πιάνεται στο preview κοστίζει ένα μήνυμα, ενώ η ίδια παρανόηση που πιάνεται μετά την κατασκευή κοστίζει δεκάδες tickets.

2.5 Μια συνέντευξη στην πράξη: «RepairFlow»

Θα ακολουθήσουμε ένα παράδειγμα σε όλο το πρόγραμμα. Μια μικρή εταιρεία επισκευής ηλεκτρονικών με τρεις τεχνικούς παρακολουθεί τις επισκευές σε ένα φύλλο Excel. Εργασίες χάνονται, προθεσμίες δεν τηρούνται και ο ιδιοκτήτης δεν μπορεί να δει ποιος κάνει τι.

Η εναρκτήρια ερώτηση είναι πάντα η ίδια: «Ποιο κομμάτι της δουλειάς σας θέλετε να οργανώσετε ή να αυτοματοποιήσετε; Περιγράψτε ένα πραγματικό παράδειγμα — τι έγινε την τελευταία φορά, βήμα-βήμα.»

Αποσπάσματα από το transcript, με την κατάσταση που απέδωσε ο Spec Builder:

Έπειτα το preview (Στάδιο P). Ο assistant έδειξε τη λίστα εργασιών ως wireframe σε κείμενο (στήλες, οι τρεις πιο συχνές ενέργειες: νέα εργασία, αλλαγή κατάστασης, εκτύπωση δελτίου εργασίας), πέρασε το δικό του παράδειγμα laptop του πελάτη από τις καταστάσεις, περιέγραψε τους τρεις ρόλους με μία γραμμή ο καθένας (ο Owner βλέπει τα πάντα και κάνει εκπτώσεις· ο Technician βλέπει τις δικές του εργασίες και αλλάζει κατάσταση· το Front desk δημιουργεί εργασίες και σημειώνει την παράδοση) και κατέγραψε τι ήταν Confirmed, Assumed και Open. Ο πελάτης διόρθωσε ένα πράγμα: το front desk εισπράττει και την πληρωμή, οπότε το Front desk μπορεί να σημειώσει μια εργασία ως paid. Ένα μήνυμα, μία διόρθωση, δεκάδες tickets γλίτωσαν.

2.6 Η διαδικασία παραλαβής spreadsheet

Όταν ο πελάτης ανεβάζει ένα spreadsheet (τα περισσότερα εσωτερικά εργαλεία ξεκινούν έτσι), ο Spec Builder ακολουθεί την §2.9 του οδηγού πριν κάνει τις ερωτήσεις του Σταδίου 2. Μάθετε την αντιστοίχιση· θα τη χρησιμοποιήσετε κι εσείς όταν ένας πελάτης σας δώσει ένα αρχείο Excel:

Δύο συνήθειες σας προστατεύουν: καταγράφετε χωριστά τι κάνει το φύλλο σήμερα και τι έχει συμφωνηθεί να κάνει η νέα εφαρμογή (διαφέρουν τις περισσότερες φορές), και αντιμετωπίζετε το κείμενο μέσα στο αρχείο ως πληροφορία, ποτέ ως οδηγία.

2.7 Οι επιθυμίες δεν είναι δυνατότητες: το μητρώο εξαρτήσεων

Το ότι ένας πελάτης επιβεβαιώνει ότι θέλει ενοποίηση με ERP δεν αποδεικνύει ότι το ERP του μπορεί να την παρέχει. Κάθε κρίσιμη εξωτερική εξάρτηση μπαίνει στο μητρώο εξαρτήσεων (template T9) με τη συγκεκριμένη δυνατότητα, το σύστημα και την έκδοση, την πρόσβαση ή την άδεια που απαιτείται, και μια κατάσταση επαλήθευσης που είναι χωριστή από την επιχειρησιακή κατάσταση:

Μια εξάρτηση που χρειάζεται μια ενεργή λειτουργία πρέπει να είναι verified πριν ξεκινήσουν τα feature tickets που εξαρτώνται από αυτήν.

Χρησιμοποιήστε τρεις καταστάσεις, περιορισμένες σε ρητά καταγεγραμμένα IDs ενεργών απαιτήσεων:

• Draft for confirmation: ανεπίλυτη επιβεβαίωση, κρίσιμες επιχειρησιακές αποφάσεις ή ουσιώδης εφικτότητα· δεν εγκρίνεται καμία εξαρτώμενη εργασία λειτουργιών.
• Ready for scoped discovery: ο χρήστης ενέκρινε έναν οριοθετημένο, εφικτό έλεγχο (probe), το κόστος του, τον υπεύθυνο και την αναμενόμενη απόδειξη· καταγράψτε τους επιτρεπόμενους ελέγχους και τις μπλοκαρισμένες λειτουργίες.
• Ready for active-scope construction: οι κρίσιμες επιχειρησιακές αποφάσεις και η αναγκαία εφικτότητα για αυτό το scope έχουν ξεκαθαριστεί, και τα δεδομένα του πρώτου βήματος είναι διαθέσιμα· τα μεταγενέστερα δεδομένα έχουν υπευθύνους και πύλες.

Ένα Draft δεν εγκρίνει αυτόματα έναν έλεγχο. Επιβεβαιώστε πρώτα το scope του discovery και το preview της εφαρμογής. Μια παλιά ετικέτα Ready to build είναι ισχυρισμός προς έλεγχο, ποτέ αυτόματη μετατροπή. Η μεταφορά απαιτήσεων στο Later χρειάζεται τη συμφωνία του χρήστη.

Ένα mock καταγράφεται ως mock_only και δεν μετρά ποτέ ως η πραγματική ενοποίηση — ο ίδιος κανόνας που ακολουθεί ο agent κατά την εκτέλεση (P5: ποτέ μην κάνετε mock μια ενοποίηση και την αναφέρετε ως λειτουργική).

2.8 Ο μηχανισμός αποφάσεων δεν είναι πρόβλημα του πελάτη

Το Μέρος 3 του οδηγού είναι ο ιδιωτικός μηχανισμός αποφάσεων του Spec Builder: αρχέτυπα, κανόνες stack, στόχοι hosting, η κλίμακα πραγματικού χρόνου, η κλίμακα κινητών, η επιλογή frontend. Ο πελάτης δεν βλέπει ποτέ τις επιλογές. Απαντά σε ερωτήσεις για τον δικό του κόσμο («πόσο γρήγορα πρέπει κάποιος να δει μια αλλαγή;», «πρέπει να δουλεύει χωρίς internet;»), και ο assistant μεταφράζει. Η Ενότητα 3 σας διδάσκει τον ίδιο μηχανισμό ώστε να μπορείτε να ελέγξετε την επιλογή.

2.9 Ομάδες review και ο τελικός έλεγχος

Εξετάστε το πλήρες προσχέδιο σε ομάδες ανάλογες με το μέγεθος της προδιαγραφής: 2 για μικρή, περίπου 5 για μεσαία και έως 10 για μεγάλη, ακολουθούμενες από τον τελικό έλεγχο συνέπειας. Καλύψτε κάθε εφαρμόσιμη οπτική και δοκιμάστε παραδείγματα στην πράξη· καταγράψτε τι ελέγχθηκε και τι άλλαξε πραγματικά. Ένα προσχέδιο που παραδίδεται νωρίς δηλώνει τις ομάδες που πράγματι ολοκληρώθηκαν. Μην ισχυρίζεστε επαλήθευση εκτέλεσης από αυτό το review.

Το PLAN MODE εκτελεί ξεχωριστό review στην πραγματική εγκατάσταση, με τους δικούς του κανόνες μεγέθους/ρυθμού. Το review του Spec Builder ούτε αντικαθιστά εκείνο το review ούτε καθορίζει τον αριθμό των tickets του.

2.10 Το πακέτο

Το αποτέλεσμα είναι ένα αρχείο Markdown (συν μια ιδέα λογότυπου σε SVG όταν χρειάζεται) με σταθερή δομή — είκοσι αριθμημένες ενότητες και παραρτήματα A–I (Planning Guide Μέρος 7). Τα μέρη που διαβάζει πρώτα ο planner της εφαρμογής:

Οι ρόλοι των tickets στο πακέτο γράφονται ακριβώς όπως τους περιμένει το CodeHero, και δεν κατονομάζεται ποτέ provider ή μοντέλο:

Πρώτα το μέγεθος: μια μικρή αλλαγή σε κάτι υπάρχον χρησιμοποιεί ένα συνηθισμένο build ticket, συν επαλήθευση όταν το απαιτούν οι περιορισμοί providers. Μια απλή νέα κατασκευή (περίπου τρεις οθόνες ή λιγότερες, ένας τύπος χρήστη, χωρίς login, χρήματα, ενοποιήσεις ή προσωπικά δεδομένα) χρησιμοποιεί ένα build και ένα VERIFY άλλης οικογένειας. Μεγαλύτερη δουλειά χρησιμοποιεί την εγκεκριμένη προδιαγραφή και ένα PLAN ticket· μόνο εκείνο το ticket σχεδιάζει και δημιουργεί τις φάσεις εργασίας.

Ένα μικρό πλάνο έχει έως περίπου πέντε tickets εργασίας, δύο ομάδες review, ένα τελικό VERIFY και REPLAN, και έναν peer για εφαρμόσιμη επικίνδυνη δουλειά. Ένα πραγματικό πλάνο χρησιμοποιεί έως δέκα ομάδες review, έναν peer και φάσεις περίπου δέκα tickets που τελειώνουν σε REPLAN. Ο γρήγορος ρυθμός (fast) χρησιμοποιεί λιγότερες ομάδες· το ultra-fast είναι ένα demo που ζητήθηκε ρητά, με δηλωμένες παραλείψεις. Οι αριθμοί είναι όρια ή εκτιμήσεις, όχι ποσοστώσεις. Οι περιορισμοί σταδιακής ενεργοποίησης providers ισχύουν σε κάθε ρυθμό.

Τα PLAN, REPLAN, PEER, VERIFY και HELPER κανονικά χρησιμοποιούν senior_developer + balanced· ένας peer/helper δεν είναι ποτέ πιο αδύναμος από αυτόν που τον άνοιξε. Το pro είναι για πολύ κρίσιμο πυρήνα ή για την τεκμηριωμένη κλιμάκωση μετά από αποτυχία. Η δουλειά γίνεται από junior_developer ανάλογα με τη δυσκολία: τετριμμένη off, πολύ απλή fast, απλή basic, μέτρια balanced· η δύσκολη δουλειά είναι senior + balanced. Το master_developer μόνο με ρητό αίτημα. Το ultra δεν είναι ποτέ προεπιλογή project ούτε αυτόματη ρύθμιση για chain tickets.

Ο κύκλος FIX 1 χρησιμοποιεί τον ρόλο και το think mode του builder· ο κύκλος 2 ανεβαίνει ένα βήμα think· ο κύκλος 3 χρησιμοποιεί senior + pro, ποτέ κάτω από τον builder. Τα επεισόδια ασφάλειας χρησιμοποιούν senior + pro· τα επεισόδια απόδοσης χρησιμοποιούν senior + balanced, με την προκαθορισμένη εξαίρεση για κρίσιμο SLA. Η δουλειά release είναι senior_developer + balanced (GUIDE: release.md). Το planning ticket εφαρμόζει τους τρέχοντες οδηγούς, τις εξαιρέσεις ρυθμού, την επιλεξιμότητα και τις επιλογές του χρήστη.

Αυτά είναι υποψήφια: το planning ticket επαναδιαστασιολογεί κάθε κάρτα ανάλογα με τη δυσκολία της στην πραγματική εγκατάσταση (§4.4).

2.11 Draft ή Ready to build

Χρησιμοποιήστε τρεις καταστάσεις, περιορισμένες σε ρητά καταγεγραμμένα IDs ενεργών απαιτήσεων:

• Draft for confirmation: ανεπίλυτη επιβεβαίωση, κρίσιμες επιχειρησιακές αποφάσεις ή ουσιώδης εφικτότητα· δεν εγκρίνεται καμία εξαρτώμενη εργασία λειτουργιών.
• Ready for scoped discovery: ο χρήστης ενέκρινε έναν οριοθετημένο, εφικτό έλεγχο (probe), το κόστος του, τον υπεύθυνο και την αναμενόμενη απόδειξη· καταγράψτε τους επιτρεπόμενους ελέγχους και τις μπλοκαρισμένες λειτουργίες.
• Ready for active-scope construction: οι κρίσιμες επιχειρησιακές αποφάσεις και η αναγκαία εφικτότητα για αυτό το scope έχουν ξεκαθαριστεί, και τα δεδομένα του πρώτου βήματος είναι διαθέσιμα· τα μεταγενέστερα δεδομένα έχουν υπευθύνους και πύλες.

Ένα Draft δεν εγκρίνει αυτόματα έναν έλεγχο. Επιβεβαιώστε πρώτα το scope του discovery και το preview της εφαρμογής. Μια παλιά ετικέτα Ready to build είναι ισχυρισμός προς έλεγχο, ποτέ αυτόματη μετατροπή. Η μεταφορά απαιτήσεων στο Later χρειάζεται τη συμφωνία του χρήστη.

2.12 Δεδομένα, υπεύθυνοι και πύλες επαφής

Καταγράψτε μόνο τα δεδομένα που απαιτεί το συμφωνημένο scope. Κάθε γραμμή ονομάζει στοιχείο, υπεύθυνο, IDs απαιτήσεων που επηρεάζονται, το βήμα πριν από το οποίο χρειάζεται, κατάσταση και απόδειξη ή αναφορά κλεισίματος· ποτέ τιμή secret. Τα δεδομένα του πρώτου βήματος πρέπει να είναι διαθέσιμα για την ετοιμότητα κατασκευής. Μεταγενέστερα δεδομένα για domain, SMTP, store, λογότυπο ή εισαγωγή περιμένουν στις ρητές πύλες τους και δεν μπλοκάρουν άσχετη εγκεκριμένη δουλειά.

Φέρτε μπροστά τις γνωστές επιχειρησιακές αποφάσεις και ομαδοποιήστε τις ερωτήσεις. Επαφές μπορεί επίσης να απαιτηθούν από scoped discovery/εναλλακτική λύση, κλιμάκωση του βρόχου διόρθωσης, έγκριση του πρώτου σταδίου από τον ιδιοκτήτη, strict ροή, δικαιώματα του execution mode, έγκριση νέας υπηρεσίας και ρητή συγκατάθεση για συγκεκριμένη καταστροφική ενέργεια. Η αυτόνομη εκτέλεση δεν καταργεί αυτές τις πύλες.

2.13 Παράδοση του πακέτου στο CodeHero

Το IMPORT αναγνωρίζει το environment_contract (και το ρητά μεταφρασμένο παλιό codehero_environment), το run contract και τα μητρώα. Διατηρεί την πηγή, επικυρώνει την ετοιμότητα του ενεργού scope, δείχνει preview της επιτρεπόμενης διαδρομής και περιμένει ρητή έγκριση πριν δημιουργήσει project/περιβάλλον/tickets. Το planning ticket σχεδιάζει στην πραγματική εγκατάσταση (Ενότητα 4)· το πλάνο tickets του πακέτου είναι το αρχικό του υλικό — υποψήφια, ποτέ tickets που δημιουργούνται όπως είναι. Το planning ticket περιέχει DAY-0 INPUTS AND OPEN ITEMS με στοιχείο, υπεύθυνο, IDs απαιτήσεων που επηρεάζονται, το βήμα πριν από το οποίο χρειάζεται, μπλοκαρισμένο scope και απόδειξη κλεισίματος. Οι τιμές secrets μένουν έξω· το ticket ονομάζει μόνο την αναφορά στο Secrets panel/path και ποιος τη δίνει.

2.14 Λίστα ελέγχου του developer για ένα πακέτο

Πριν εισαγάγετε ένα πακέτο, ελέγξτε:

• &#9744; Κάθε απαίτηση εκτός Later έχει τουλάχιστον ένα ID αποδοχής και ένα ορόσημο (Παράρτημα G).
• &#9744; Κάθε επιχειρησιακός κανόνας στην §7 έχει αριθμό και παράδειγμα με τις τιμές του πελάτη.
• &#9744; Το Παράρτημα F καταγράφει κάθε στοιχείο Assumed, κάθε στοιχείο Open και κάθε απαίτηση με προέλευση agent.
• &#9744; Τα κρίσιμα στοιχεία (χρήματα, εγκρίσεις, διαγραφή, νομικά, ασφάλεια) είναι Confirmed ή ρητά Open — κανένα δεν είναι Assumed.
• &#9744; Κάθε κρίσιμη εξωτερική εξάρτηση έχει γραμμή T9 με κατάσταση επαλήθευσης· τίποτα που χρειάζεται το ενεργό scope δεν είναι pending χωρίς probe ticket.
• &#9744; Χρησιμοποιήστε το τρέχον environment_contract από το CODEHERO_PLANNING_GUIDE.md §3.3. Διατηρήστε όλα τα πεδία runtime, ιδιοκτησίας υπηρεσιών, βάσης δεδομένων, εργασιών παρασκηνίου/προγραμματισμένων, πραγματικού χρόνου, build/υπογραφής/συσκευών, εξυπηρέτησης, εναλλακτικής λύσης, ελέγχου και ενεργοποίησης. Αντιμετωπίστε το codehero_environment μόνο ως παλιά δεδομένα εισαγωγής, με ρητή μετάφραση και διατήρηση των αγνώστων.
• &#9744; Το πλάνο tickets είναι σειριακό (αυστηρά αύξοντες, διακριτοί αριθμοί σειράς). Το PLAN καταγράφει το ίδιο την αρχιτεκτονική και τις αποφάσεις στη γνώση του project. Το πρώτο SETUP ticket ελέγχει τις δυνατότητες και την ετοιμότητα εφαρμογής/υπηρεσιών· δημιουργήστε ξεχωριστό discovery probe μόνο όταν το εγκεκριμένο scope πράγματι το απαιτεί. Ακολουθεί η λεπτότερη χρήσιμη επιβεβαιωμένη ροή, όχι σταθερός αριθμός θεμελιωδών tickets.
• &#9744; Κάθε ticket παραπέμπει σε IDs απαιτήσεων. Παραλείψτε ονόματα containers, εσωτερικές IP containers και εντολές εισόδου από την πλευρά του host από τις οδηγίες των tickets· διατηρήστε το αληθές environment contract και ακολουθήστε το execution context που δίνεται. Ένα container SETUP μπορεί να καλύψει εγκεκριμένα κενά υπηρεσιών μέσω του GUIDE: services.md· η εγκατάσταση στο σύστημα του host παραμένει δεδομένο του operator.
• &#9744; Τα παραδοτέα τεκμηρίωσης καταγράφονται στη γλώσσα του πελάτη.
• &#9744; Το Παράρτημα E έχει πραγματικές γραμμές review, και ο δηλωμένος αριθμός γύρων ταιριάζει.

Ασκήσεις — Ενότητα 2

1. Διεξάγετε μια συνέντευξη. Συνεργαστείτε με έναν συνάδελφο που παίζει τον πελάτη (το βιβλίο ραντεβού μιας οδοντιατρικής κλινικής, το φύλλο αποθέματος μιας αποθήκης, τη λίστα παρουσιών ενός σχολείου). Ρυθμίστε τον Spec Builder και αφήστε τον «πελάτη» να απαντήσει. Μην απαντάτε εσείς σε επιχειρησιακές ερωτήσεις. Παραδώστε το πακέτο.
2. Ελέγξτε τις καταστάσεις. Στο πακέτο, μετρήστε Confirmed / Assumed / Technical / Open. Για κάθε στοιχείο Assumed γράψτε τη μία πρόταση που πρέπει να επιβεβαιώσει ο πελάτης. Για κάθε κρίσιμο στοιχείο ελέγξτε ότι δεν είναι Assumed.
3. Παραλαβή spreadsheet. Πάρτε οποιοδήποτε πραγματικό spreadsheet έχετε. Εφαρμόστε την §2.6 με το χέρι: οντότητες, πεδία, τύποι → κανόνες, χρώματα → καταστάσεις, χειροκίνητα βήματα → εργασίες. Συγκρίνετε με ό,τι παρήγαγε ο Spec Builder από το ίδιο αρχείο.
4. Βρείτε την επιθυμία. Στο πακέτο σας, βρείτε μία εξάρτηση που ο πελάτης θέλει αλλά κανείς δεν έχει επαληθεύσει. Γράψτε τη γραμμή T9 της και το probe ticket που θα την επαλήθευε.
5. Γύροι review. Διαλέξτε πέντε οπτικές από το Μέρος 6 του οδηγού και εφαρμόστε τες μόνοι σας στο πακέτο σας, καταγράφοντας τα ευρήματα στη μορφή T6. Βρήκατε κάτι που έχασαν οι καταγεγραμμένες ομάδες review; (Συνήθως ναι — γι' αυτό κάνει review ο developer.)

---

ΜΕΡΟΣ III — ΕΠΙΛΟΓΗ ΤΟΥ STACK

Ενότητα 3 — Πώς και γιατί το CodeHero επιλέγει PHP, Node, Python ή .NET

3.1 Η αρχή: η σωστή εφαρμογή για αυτόν τον πελάτη

Η κεντρική αρχή του Spec Builder (Planning Guide §1.1) είναι η καταλληλότητα: η λύση ταιριάζει στις πραγματικές ανάγκες της εφαρμογής, στον αρχικό προϋπολογισμό και στο αποδεκτό μηνιαίο κόστος, στις γνώσεις της ομάδας του πελάτη, στην υπάρχουσα υποδομή του και στην ικανότητά του να εγκαταστήσει και να συντηρήσει ό,τι προδιαγράφετε. Ένα τεχνικά ανώτερο stack που ο πελάτης δεν μπορεί να φιλοξενήσει ή να συντηρήσει είναι το λάθος stack.

Γι' αυτό το stack αποφασίζεται μετά το Στάδιο C (περιορισμοί), ποτέ μόνο από το αρχέτυπο, και γι' αυτό κάθε απόκλιση από την προεπιλογή φέρει αιτιολόγηση μίας γραμμής στην προδιαγραφή. Όταν ελέγχετε ένα πακέτο ή ένα γρήγορο πλάνο, αναζητήστε αυτή τη γραμμή. Αν λείπει, η επιλογή ήταν προτίμηση, όχι απόφαση.

3.2 Πρώτα PHP, πρώτα MySQL — και γιατί

Το προεπιλεγμένο backend του CodeHero είναι PHP ≥ 8.2 με MySQL ≥ 8, σε συνηθισμένο web hosting όταν το επιτρέπει ο σχεδιασμός. Οι λόγοι είναι πρακτικοί, και πρέπει να μπορείτε να τους εξηγήσετε σε έναν πελάτη:

Το προφίλ PHP καλύπτει: REST APIs, εσωτερικές επιχειρησιακές εφαρμογές, portals και συστήματα διαχείρισης, backends για mobile apps, δυναμικούς ιστότοπους και ενοποιήσεις που εξυπηρετούνται με συνηθισμένα requests ή περιοδικές εργασίες. Ένα REST API, σύνθετες οθόνες ή εμφάνιση τύπου εφαρμογής δεν είναι λόγοι να εγκαταλείψετε την PHP. Ούτε οι «πολλοί χρήστες» — το φορτίο κρίνεται από έναν αντιπροσωπευτικό φόρτο εργασίας που περιγράφεται στην προδιαγραφή και επαληθεύεται στην πύλη πρόσβασης ή σε load test, ποτέ από εμπειρικό κανόνα.

Η MySQL μένει η προεπιλογή με κάθε backend. Το backend και η βάση δεδομένων αποφασίζονται χωριστά: η Python δεν συνεπάγεται PostgreSQL και το .NET δεν συνεπάγεται SQL Server. Η PostgreSQL ή ο SQL Server εμφανίζονται μόνο όταν τα ζητήσει ο πελάτης, όταν τα απαιτεί ένα υπάρχον περιβάλλον ή μια ενοποίηση, ή όταν καταγράφεται συγκεκριμένος λόγος εφαρμογής.

3.3 Πότε εγκαταλείπετε την PHP — οι μόνες αφορμές

Τα server-sent events δεν ενεργοποιούν τη γραμμή των WebSockets εφόσον επαληθεύονται στο πραγματικό hosting για timeouts, buffering και επανασύνδεση. Αν καμία ανάγκη δεν δικαιολογεί διαφορετικό backend, επιλέξτε PHP/MySQL. Δηλώστε τις απαιτούμενες δυνατότητες hosting και την πύλη επαλήθευσής τους· μην ισχυρίζεστε ότι ένας συγκεκριμένος host είναι κατάλληλος ή ότι δεν χρειάζεται container μέχρι να είναι γνωστές οι δυνατότητές του.

3.4 Τα αρχέτυπα (τι σημαίνουν συνήθως τα σήματα)

3.5 Οι κλίμακες: διαλέξτε το χαμηλότερο σκαλί που ικανοποιεί τις απαντήσεις

Κλίμακα πραγματικού χρόνου (από τις απαντήσεις του Σταδίου 5):

1. Με ανανέωση — ιστότοποι περιεχομένου.
2. Polling κάθε 15–60 s — τα περισσότερα εσωτερικά εργαλεία· οποιοδήποτε hosting· T-PHP.
3. Polling κάθε 5 s + ένδειξη μέσα στην εφαρμογή — λειτουργικά εργαλεία όπου ένα λεπτό είναι πολύ αργό· ακόμη T-PHP.
4. Server-sent events — μονόδρομες ζωντανές ροές· T-PHP όπου το υποστηρίζει ο πάροχος και έχει επαληθευτεί· χρησιμοποιήστε κατάλληλο επαληθευμένο υπάρχον hosting/native υποδομή, ή εγκεκριμένο platform container όταν οι απαιτούμενες δυνατότητες δεν είναι αλλιώς διαθέσιμες. Οι ανάγκες runtime, τα εργαλεία build και το provisioning είναι χωριστές αποφάσεις· διατηρήστε τους περιορισμούς του χρήστη.
5. WebSockets με ανθεκτική ροή συμβάντων — συναγερμοί, ζωντανοί πίνακες, επεξεργασία από πολλούς χρήστες· χρησιμοποιήστε κατάλληλο επαληθευμένο υπάρχον hosting/native υποδομή, ή εγκεκριμένο platform container όταν οι απαιτούμενες δυνατότητες δεν είναι αλλιώς διαθέσιμες. Οι ανάγκες runtime, τα εργαλεία build και το provisioning είναι χωριστές αποφάσεις· διατηρήστε τους περιορισμούς του χρήστη. Μοτίβο: συμβάντα από database outbox με cursor, επανάληψη κατά την επανασύνδεση, heartbeat με ορατή αποσύνδεση, αποδείξεις λήψης.

Κλίμακα κινητών:

1. Responsive web app — προϊόντα με web σελίδες για ανθρώπους χρησιμοποιούν responsive διατάξεις· APIs, CLIs και αποκλειστικά native προϊόντα δεν αποκτούν από προεπιλογή νέο web app.
2. Web app με δυνατότητα εγκατάστασης (PWA) — εικονίδιο στην αρχική οθόνη, offline cache μόνο για ανάγνωση, web push.
3. Wrapper Capacitor — το ίδιο web app στα stores· native plugins για κάμερα, barcode, GPS, push, βιομετρικά. Απαιτεί developer accounts σε Apple και Google (ημέρα 0).
4. React Native / Expo — μόνο αν η ομάδα του πελάτη βασίζεται σε React και το ζητήσει.
5. Native Swift/Kotlin — μόνο για τις συνθήκες του A9.

Frontend, επιλεγμένο ανάλογα με την ανάγκη και χωριστά από το backend: μια απλή σελίδα παρουσίασης → HTML + Tailwind, ελάχιστο JS· απλές φόρμες → σελίδες που αποδίδονται στον server + Alpine.js· σύνθετες οθόνες με πολλές αλληλεπιδράσεις → Vue (προτιμάται PrimeVue). Δηλώστε τα απαιτούμενα εργαλεία build και έναν επαληθευμένο υπεύθυνο/περιβάλλον build χωριστά από τον host του runtime. Ένας στόχος deploy που σερβίρει προκατασκευασμένα στατικά αρχεία δεν χρειάζεται να τρέχει Node, αλλά αυτό δεν αποδεικνύει ότι υπάρχει ήδη κατάλληλο περιβάλλον build. Το planning ticket επιλέγει τα paths εξόδου και τη ροή πακεταρίσματος της πλατφόρμας.

3.6 Runtime, εργαλεία build και εξυπηρέτηση — τρεις χωριστές δηλώσεις

Η πιο συνηθισμένη σύγχυση. Το block codehero_environment τα διαχωρίζει σκόπιμα:

Η Ενότητα 14 του global context αντικατοπτρίζει αυτό κατά την εκτέλεση — το πού βρίσκεται ο χώρος εργασίας build εξαρτάται από τη μορφή του project:

3.7 Τι παρέχει το CodeHero — ώστε να μη σχεδιάζετε ποτέ tickets «εγκατάστασε PHP»

Projects στον host. Ubuntu 24.04, nginx, PHP 8.3, Node 22, Python 3.12, MySQL 8.0 (global §13). Κάθε project παίρνει τη δική του βάση MySQL και χρήστη· τα διαπιστευτήρια εμφανίζονται στο block PROJECT DATABASE του agent. Οι τοπικές βιβλιοθήκες βρίσκονται στο /opt/codehero/libs/.

Διατηρήστε το εγκεκριμένο environment_contract στην προδιαγραφή. Οι οδηγίες των tickets περιγράφουν το πραγματικό περιβάλλον εκτέλεσης του project, τα paths του project, τα ports των τοπικών υπηρεσιών και τις αναφορές σε secrets· παραλείπουν ονόματα containers, εσωτερικές IP containers και εντολές εισόδου από την πλευρά του host. Οι υπηρεσίες στο ίδιο μηχάνημα χρησιμοποιούν localhost:<verified port>· οι εξωτερικές υπηρεσίες κρατούν τα πραγματικά τους endpoints. Οι έλεγχοι σε browser χρησιμοποιούν το preview URL της πλατφόρμας.

Μετά την έγκριση, δημιουργήστε μέσω MCP το project και το δηλωμένο platform container και το περιβάλλον του καταλόγου πριν από το planning ticket. Το nginx είναι ενσωματωμένο και δεν δηλώνεται ποτέ ως πρόσθετη υπηρεσία. Το planning ticket μπορεί να ανακαλύψει ένα εγκεκριμένο κενό υπηρεσίας: το SETUP ticket του μπορεί να το εγκαταστήσει ή να το καταχωρίσει μέσα στο container του project σύμφωνα με το GUIDE: services.md. Τα runtimes του host που λείπουν είναι δεδομένα με υπεύθυνο τον operator· τα tickets δεν τα εγκαθιστούν.

Η καταστροφή, η μετεγκατάσταση, η διακοπή του container και η επαναφορά ή διαγραφή ενός snapshot απαιτούν το ρητό ναι του χρήστη για τη συγκεκριμένη ενέργεια. Για τις υποστηριζόμενες ενέργειες container, περάστε user_confirmed=true μόνο μετά από εκείνο το ναι. Μην επινοείτε ποτέ ενέργεια δικτύου ή παράμετρο που δεν υπάρχει στο ζωντανό schema.

3.8 Τύπος project και paths

Το project_type ελέγχει την υποστηριζόμενη κατηγορία project/path· το project_stack επιλέγει ρητά τις εγκατεστημένες ενότητες stack. Οι έγκυρες επιλογές stack είναι php, node, python, mysql, html, java, dotnet, go, react, react_native, capacitor, flutter, kotlin και swift. Μην περνάτε capacitor, native-android ή dotnet ως επινοημένες τιμές project_type, και μη χρησιμοποιείτε το react ως context για React Native. Οι καρφωμένες εκδόσεις runtime (php_version, node_version, python_version, …) μπορούν να δοθούν κατά τη δημιουργία και εμφανίζονται στο block RUNTIME ENVIRONMENT του agent.

3.9 Το block περιβάλλοντος, πεδίο προς πεδίο

environment_contract:
  deployment_mode: <standard-hosting|native-host|platform-container|existing-infrastructure>
  container_policy: <allowed|forbidden>
  initial_target: <confirmed target or owned open item>
  future_target: <confirmed target|none|owned open item>
  services:
    - {name: <required service>, runtime: <required runtime>, install_owner: <role>, lifecycle_owner: <role>}
  database: <required database|none>
  long_running_processes: <required processes|none>
  scheduled_jobs: <confirmed need, duration, overlap, retry and interruption rules|none>
  realtime_by_use_case: <requirement IDs, acceptable delays and evidence|{}>
  build: {web: <need|none>, android: <need|none>, ios: <need|none>, ios_path: <path/owner|none>, signing: <owner/reference|none>, test_devices: <devices/owner|none>}
  build_container: <required build environment|none>
  served_by: <runtime serving the deployed output>
  fallback_stack: <equivalent approved option|none>
  test_environment: isolated-local
  production_activation: separate-gate
# Container disk size (GB): <preview-confirmed requirement, or not applicable>
# Availability/evidence: <references to capability register rows; never inferred from this template>

Επιλέξτε το deployment_mode από τον επιβεβαιωμένο στόχο, τις πραγματικές δυνατότητες και τους περιορισμούς του χρήστη· δεν υπάρχει προεπιλογή platform-container που να καθορίζεται από τη γλώσσα. Η υπάρχουσα χειροκίνητη υποδομή έχει κατονομαζόμενο operator και πύλη πρόσβασης. Μια δυνατότητα του host που λείπει είναι δεδομένο του operator· τα εγκεκριμένα κενά container από τον κατάλογο ή προσαρμοσμένα καλύπτονται από το SETUP σύμφωνα με το GUIDE: services.md.

Το fallback_stack υπάρχει επειδή η αρχιτεκτονική επιλέγεται πριν ελεγχθεί η εγκατάσταση. Αν το ticket #0 (ο έλεγχος δυνατοτήτων) βρει ότι το runtime δεν μπορεί να παρασχεθεί, η εκτέλεση σταματά με ερώτηση προς τον ιδιοκτήτη και προτείνει την εναλλακτική λύση — μόνο αν εξακολουθεί να περνά τα ίδια κριτήρια αποδοχής. Μια εναλλακτική που αλλάζει μια συμφωνημένη δυνατότητα (ταχύτητα ενημέρωσης, ζωντανοί συναγερμοί, χρήση offline) είναι αλλαγή απαιτήσεων, όχι τεχνική αντικατάσταση, και κάθε ID απαίτησης που επηρεάζεται πρέπει να κατονομάζεται.

3.10 Δύο αντιθετικά παραδείγματα

RepairFlow (A3, εσωτερικό εργαλείο). Απαντήσεις Σταδίου C: περιστασιακές ενοποιήσεις (μόνο email), χωρίς offline, χωρίς χρονικά όρια, συνηθισμένο web hosting, ελάχιστο μηνιαίο κόστος. Στάδιο 5: «με ανανέωση είναι εντάξει». Καμία αφορμή για να εγκαταλειφθεί η PHP. Απόφαση καταγεγραμμένη στην προδιαγραφή: «Επιλέχθηκε PHP/MySQL· τρέχει σε συνηθισμένο web hosting· δεν απαιτείται container.»

environment_contract:
  deployment_mode: standard-hosting
  container_policy: allowed
  initial_target: <confirmed target; capabilities to be verified>
  future_target: <agreed target|none|owned open item>
  services:
    - {name: web, runtime: php, install_owner: host-operator, lifecycle_owner: host-operator}
    - {name: database, runtime: mysql, install_owner: host-operator, lifecycle_owner: host-operator}
  database: mysql
  long_running_processes: none
  scheduled_jobs: <only confirmed overdue/notification work; cadence, overlap, retries and interruption rules>
  realtime_by_use_case:
    job_status: {acceptable_delay: "visible when the user refreshes", transport: manual-refresh}
  build: {web: <needed and verified tool|none>, android: none, ios: none, ios_path: none, signing: none, test_devices: none}
  build_container: none
  served_by: php-host-static-files
  fallback_stack: none
  test_environment: isolated-local
  production_activation: separate-gate
# Host availability and the acceptable monthly cost still require their own evidence/decision.
# Do not turn a spreadsheet highlight into a scheduled email or an agreed hosting-only budget.

Project στο CodeHero: project_type: web, tech_stack: php, web_path: /var/www/projects/repairflow, χωρίς container.

AlarmBoard (A5, παρακολούθηση σε πραγματικό χρόνο). Ένας χώρος logistics με 40 αισθητήρες θερμοκρασίας· το κριτήριο αποδοχής λέει «μια μέτρηση εκτός ορίων εμφανίζεται στην οθόνη λειτουργιών μέσα σε 2 δευτερόλεπτα, μετρημένα από το timestamp του αισθητήρα έως την ειδοποίηση στην οθόνη». Στάδιο 5: μετρούν τα δευτερόλεπτα· οι συσκευές στέλνουν δεδομένα συνεχώς. Ενεργοποιούνται δύο αφορμές (WebSockets από κριτήριο αποδοχής· συνεχής επεξεργασία). Απόφαση: T-NODE σε container, με τη γραμμή αιτιολόγησης «Η ειδοποίηση μέσω WebSocket εντός 2 s απαιτείται από το A07· η ροή αισθητήρων χρειάζεται μόνιμο worker.»

environment_contract:
  deployment_mode: platform-container
  container_policy: allowed
  initial_target: codehero-host
  future_target: none
  services:
    - {name: application, runtime: node, install_owner: codehero, lifecycle_owner: codehero}
    - {name: database, runtime: mysql, install_owner: codehero, lifecycle_owner: codehero}
    - {name: cache, runtime: redis, install_owner: codehero, lifecycle_owner: codehero}
  database: mysql
  long_running_processes: [api, workers, websocket-gateway]
  scheduled_jobs: <worker-queue duration, overlap, retries and interruption behavior to be established>
  realtime_by_use_case:
    A07: {required_delay: "sensor timestamp to visible alert <= 2 seconds", transport: websocket, evidence: pending}
  build: {web: vite, android: none, ios: none, ios_path: none, signing: none, test_devices: none}
  build_container: <needed build tooling; availability not yet verified>
  served_by: nginx-static
  fallback_stack: none
  test_environment: isolated-local
  production_activation: separate-gate
# Example only: use these service choices and owners only if confirmed for this installation.
# nginx is built in, not an additional service. Container disk size is confirmed in the preview.
# Polling every 5 seconds cannot satisfy A07 and is not an equivalent fallback.
# Until the necessary feasibility is evidenced, this example is discovery scope, not construction-ready.

Project στο CodeHero: project_type: web (σερβίρει την οθόνη λειτουργιών), tech_stack: node, web_path: /var/www/projects/alarmboard, container δημιουργημένο μέσω codehero_container_operations με τις δηλωμένες υπηρεσίες πριν από οποιοδήποτε ticket.

3.11 Οκτώ μικρές περιπτώσεις (αποφασίστε, μετά ελέγξτε)

3.12 Πώς γράφεται η αιτιολόγηση

Μία γραμμή, στην κεφαλίδα της προδιαγραφής και ξανά στο preview του planner όταν το stack δεν είναι PHP + MySQL. Το μοτίβο: ID απαίτησης → η δυνατότητα που χρειάζεται → γιατί η PHP δεν μπορεί να την παρέχει → το επιλεγμένο stack.

Μια αιτιολόγηση που κατονομάζει μια προτίμηση («το Node είναι πιο σύγχρονο») αντί για μια απαίτηση δεν είναι αιτιολόγηση. Επιστρέψτε την.

Ασκήσεις — Ενότητα 3

1. Για καθεμία από τις οκτώ μικρές περιπτώσεις, γράψτε το block codehero_environment. Συγκρίνετε με έναν συνάδελφο· κάθε διαφορά πρέπει να εξηγείται από μια απαίτηση.
2. Πάρτε το πακέτο σας από την Ενότητα 2. Βρείτε την απόφαση stack. Υπάρχει αιτιολόγηση μίας γραμμής; Παραπέμπει σε ID απαίτησης; Αν το stack είναι PHP, λέει ρητά η προδιαγραφή «δεν απαιτείται container»;
3. Ξαναγράψτε αυτό το κακό απόσπασμα πλάνου ώστε να σέβεται την §3.7: "Ticket 1: Install Node 20 and MySQL in the container. Ticket 2: Configure nginx to proxy port 3000. Ticket 3: Create the schema."
4. Ένας πελάτης επιμένει σε PostgreSQL «επειδή είναι καλύτερη». Γράψτε τις δύο προτάσεις που θα λέγατε, και τη γραμμή που θα καταγράφατε στο Decision Log αν εξακολουθεί να επιμένει.
5. Εξηγήστε σε έναν μη τεχνικό πελάτη, σε τρεις προτάσεις, γιατί το εσωτερικό του εργαλείο θα τρέχει στο υπάρχον web hosting του και τι του γλιτώνει αυτό κάθε μήνα.

---

ΜΕΡΟΣ IV — ΣΧΕΔΙΑΣΜΟΣ

Ενότητα 4 — Από το πακέτο στο project: ο planner της εφαρμογής και το πλάνο tickets

4.1 Πού γίνεται ο σχεδιασμός — δύο σημεία, μία μέθοδος

Ανοίξτε τον AI Assistant στο CodeHero και επιλέξτε Plan with AI. Ο assistant τρέχει με οδηγίες το config/assistant-planner.md συν το global context, και έχει τα εργαλεία codehero_*. Κάνει καλά δύο πράγματα: γνωρίζει αυτή την εγκατάσταση (ενεργούς providers, ports, υποστήριξη containers), και μπορεί να δημιουργήσει το project και το περιβάλλον του. Δεν σχεδιάζει κανένα ticket. Γράφει την προδιαγραφή μαζί σας (ή εισάγει ένα πακέτο Spec Builder), ξεκαθαρίζει ό,τι μπορεί να αποφασίσει μόνο άνθρωπος, δείχνει preview, και αφού επιβεβαιώσετε δημιουργεί το project, το container όταν το δηλώνει το environment contract, και ακριβώς ένα ticket: το planning ticket ([PLAN] <project> — baseline and phase 1). Πρώτα το μέγεθος: οι μικρές αλλαγές σε υπάρχοντα projects και οι απλές νέες κατασκευές χρησιμοποιούν τις ρητές εξαιρέσεις τους.

Το planning ticket τρέχει σε PLAN MODE (guides/planning.md, προφορτωμένο για αυτό από τον daemon) στην πραγματική εγκατάσταση: αποθηκεύει την προδιαγραφή ως το αμετάβλητο baseline (.specs/000-baseline.md), διαβάζει τους ενεργούς providers, γράφει το αρχείο πλάνου (απαιτήσεις με παραδείγματα αποδοχής, ρόλοι, stack, ρυθμίσεις εκτέλεσης, ανοιχτές ερωτήσεις), γεμίζει τη knowledge base, γράφει ένα SPEC FILE ανά υποεργασία με πρώτα τα κοινά contracts, ταξινομεί τη δουλειά κατά αξία, εκτελεί μια δοκιμαστική εκτέλεση (dry run) του πλάνου και τους γύρους review του, παίρνει έναν έλεγχο από peer από άλλον provider, και δημιουργεί την πρώτη φάση tickets. Κάθε μεταγενέστερη φάση δημιουργείται από το ticket [REPLAN] που κλείνει την προηγούμενη. Το ίδιο PLAN MODE τρέχει όταν ένας χρήστης ανοίγει ένα ticket με το χέρι και λέει «σχεδίασε»: μία μέθοδος σε ένα σημείο.

Πρώτα το μέγεθος: μια μικρή αλλαγή σε κάτι υπάρχον χρησιμοποιεί ένα συνηθισμένο build ticket, συν επαλήθευση όταν το απαιτούν οι περιορισμοί providers. Μια απλή νέα κατασκευή (περίπου τρεις οθόνες ή λιγότερες, ένας τύπος χρήστη, χωρίς login, χρήματα, ενοποιήσεις ή προσωπικά δεδομένα) χρησιμοποιεί ένα build και ένα VERIFY άλλης οικογένειας. Μεγαλύτερη δουλειά χρησιμοποιεί την εγκεκριμένη προδιαγραφή και ένα PLAN ticket· μόνο εκείνο το ticket σχεδιάζει και δημιουργεί τις φάσεις εργασίας.

Ένα μικρό πλάνο έχει έως περίπου πέντε tickets εργασίας, δύο ομάδες review, ένα τελικό VERIFY και REPLAN, και έναν peer για εφαρμόσιμη επικίνδυνη δουλειά. Ένα πραγματικό πλάνο χρησιμοποιεί έως δέκα ομάδες review, έναν peer και φάσεις περίπου δέκα tickets που τελειώνουν σε REPLAN. Ο γρήγορος ρυθμός (fast) χρησιμοποιεί λιγότερες ομάδες· το ultra-fast είναι ένα demo που ζητήθηκε ρητά, με δηλωμένες παραλείψεις. Οι αριθμοί είναι όρια ή εκτιμήσεις, όχι ποσοστώσεις. Οι περιορισμοί σταδιακής ενεργοποίησης providers ισχύουν σε κάθε ρυθμό.

Τα PLAN, REPLAN, PEER, VERIFY και HELPER κανονικά χρησιμοποιούν senior_developer + balanced· ένας peer/helper δεν είναι ποτέ πιο αδύναμος από αυτόν που τον άνοιξε. Το pro είναι για πολύ κρίσιμο πυρήνα ή για την τεκμηριωμένη κλιμάκωση μετά από αποτυχία. Η δουλειά γίνεται από junior_developer ανάλογα με τη δυσκολία: τετριμμένη off, πολύ απλή fast, απλή basic, μέτρια balanced· η δύσκολη δουλειά είναι senior + balanced. Το master_developer μόνο με ρητό αίτημα. Το ultra δεν είναι ποτέ προεπιλογή project ούτε αυτόματη ρύθμιση για chain tickets.

Ο κύκλος FIX 1 χρησιμοποιεί τον ρόλο και το think mode του builder· ο κύκλος 2 ανεβαίνει ένα βήμα think· ο κύκλος 3 χρησιμοποιεί senior + pro, ποτέ κάτω από τον builder. Τα επεισόδια ασφάλειας χρησιμοποιούν senior + pro· τα επεισόδια απόδοσης χρησιμοποιούν senior + balanced, με την προκαθορισμένη εξαίρεση για κρίσιμο SLA. Η δουλειά release είναι senior_developer + balanced (GUIDE: release.md). Το planning ticket εφαρμόζει τους τρέχοντες οδηγούς, τις εξαιρέσεις ρυθμού, την επιλεξιμότητα και τις επιλογές του χρήστη.

4.2 Οι κανόνες του assistant που σας αφορούν

1. Μόνο εργαλεία MCP. Το project, το περιβάλλον και το planning ticket δημιουργούνται με τα codehero_create_project, codehero_container_operations και codehero_bulk_create_tickets (με ένα ticket) — ποτέ με SQL, curl ή μέσω του UI για λογαριασμό του assistant.
2. Πρώτα το codehero_get_providers_info. Η μοναδική πηγή αλήθειας για τους ενεργούς providers, τα βάρη κόστους και ικανότητας (smart) ανά ρόλο, την υποστήριξη vision και thinking· ο assistant δεν σχεδιάζει ποτέ από μνήμης. Το planning ticket το διαβάζει ξανά μόνο του, μαζί με το codehero_get_model_table (κάθε μοντέλο κάθε ενεργού provider, §4.4).
3. Μόνο ενεργοί providers, για την προεπιλογή του project και για το planning ticket.
4. Πρώτα το μέγεθος: οι μικρές αλλαγές σε υπάρχοντα projects και οι απλές νέες κατασκευές χρησιμοποιούν τις ρητές εξαιρέσεις τους. Η μεγαλύτερη δουλειά BUILD/IMPORT δημιουργεί ένα PLAN που φέρει την αμετάβλητη προδιαγραφή· οι υποψήφιες κάρτες δεν είναι έτοιμο μαζικό πλάνο.
5. Preview → ρητή επιβεβαίωση → δημιουργία. Ρυθμίσεις, σύνοψη προδιαγραφής, δεδομένα ημέρας 0, ρυθμίσεις εκτέλεσης, έπειτα «yes / ok / ναι / προχώρα». Το «κάνε ό,τι νομίζεις» εκχωρεί αποφάσεις, όχι το preview.
6. Οι επιχειρησιακές αποφάσεις ανήκουν σε εσάς (χρήματα, δικαιώματα, εγκρίσεις, διαγραφή, διατήρηση δεδομένων, ασφάλεια, scope, κόστος). Ένα κενό σημειώνεται open, δεν συμπληρώνεται ποτέ με επινοημένη προεπιλογή. Φέρτε μπροστά την ανθρώπινη συμβολή: μόλις ξεκινήσει το planning ticket, η εκτέλεση είναι αυτόνομη και μια επιχειρησιακή απόφαση που λείπει τη σταματά.
7. Το περιβάλλον δεν είναι δουλειά tickets — τα containers και οι υπηρεσίες δημιουργούνται πριν από το planning ticket. Παραλείψτε ονόματα containers, εσωτερικές IP containers και εντολές εισόδου από την πλευρά του host από τις οδηγίες των tickets· διατηρήστε το αληθές environment contract και ακολουθήστε το execution context που δίνεται. Ένα container SETUP μπορεί να καλύψει εγκεκριμένα κενά υπηρεσιών μέσω του GUIDE: services.md· η εγκατάσταση στο σύστημα του host παραμένει δεδομένο του operator.
8. Κάθε ρύθμιση εκτέλεσης εμφανίζεται στο preview και στο run contract ανώτατου επιπέδου. Στα εργαλεία περνούν μόνο πραγματικές παράμετροι του schema: τα execution_mode και deps_include_awaiting δίνονται ρητά στη δημιουργία μεμονωμένων/μαζικών tickets· τα strategy, pace, parallel, plan_approval και release_policy μένουν δεδομένα του contract.
9. Γλώσσα και φωνητική λειτουργία, όπως παντού.

4.3 Τρεις λειτουργίες

Προεπιλογές: εκτέλεση autonomous, ροή relaxed (deps_include_awaiting: true), strategy balanced, σειριακά, έγκριση πλάνου autonomous (εγκρίνατε το preview· το planning ticket δεν ρωτά ξανά — ορίστε plan_approval: owner-approves-first-stage αν θέλετε να δείτε τον πίνακα tickets πριν δημιουργηθούν τα tickets εργασίας του πρώτου σταδίου), release policy none (ένα σοβαρό project — που εγκαθίσταται ή αναβαθμίζεται εκτός αυτού του server, ή που κρατά επιχειρησιακά δεδομένα που μια αναβάθμιση δεν πρέπει να χάσει — παίρνει at-milestones: ο assistant το προτείνει στο preview, και το planning ticket κρίνει ξανά όταν το contract το παραλείπει), think mode του project balanced. Το ultra δεν είναι ποτέ προεπιλογή project· το ίδιο το planning ticket τρέχει senior_developer (master_developer μόνο όταν το ζητήσετε) — balanced· pro μόνο για πολύ κρίσιμο πυρήνα ή τεκμηριωμένη κλιμάκωση μετά από αποτυχία — κατά προτίμηση σε anthropic ή openai, αλλιώς στον ισχυρότερο ενεργό provider που υποστηρίζει thinking.

4.4 Providers, ρόλοι, think modes, strategy — η δουλειά του planning ticket

Ρόλοι, όχι μοντέλα. Ένα ticket αποθηκεύει ai_model = master_developer / senior_developer / junior_developer. Ποιο συγκεκριμένο μοντέλο σημαίνει αυτό εξαρτάται από τον provider, μέσω του heroagent/heroagent.conf (model_aliases). Η προσθήκη νέου μοντέλου στην πλατφόρμα είναι επεξεργασία config· κανένα ticket δεν αλλάζει.

Μοντέλα ανάλογα με την αξία τους (5.0.1). Ένας provider συνήθως προσφέρει περισσότερα μοντέλα από τις τρεις προεπιλογές ρόλων του. Το codehero_get_model_table τα καταγράφει όλα: provider · μοντέλο · οι ρόλοι που το χρησιμοποιούν · vision · κόστος ανά 1M tokens · πραγματικό κόστος (ένα subscription μετρά 1/10) · βαθμολογία · ο ρόλος που κερδίζει η βαθμολογία · από πού προέρχεται η βαθμολογία (η δική μας αξιολόγηση στο model_ratings, ή εκτίμηση μέχρι να μετρηθεί ένα μοντέλο). Το planning ticket μπορεί να ορίσει ένα συγκεκριμένο μοντέλο του provider του ticket στο πεδίο model του ticket — το φθηνότερο επιλέξιμο μοντέλο που καλύπτει τον ρόλο, κατανεμημένα ώστε κάθε μοντέλο να δουλεύει και να μετριέται· χωρίς αυτό τρέχει η προεπιλογή του ρόλου. Οι προϋπολογισμοί του ticket (context window, έξοδος, compaction) ακολουθούν το μοντέλο που πραγματικά τρέχει. Όταν ένα μοντέλο καλύπτει δύο ρόλους ενός provider, ο ανώτερος ρόλος σκέφτεται αυτόματα ένα βήμα περισσότερο (ποτέ πάνω από pro· το δικό του think mode του ticket υπερισχύει).

Οικονομία χωρίς απώλεια ποιότητας. Ξοδέψτε εκεί όπου ένα λάθος πολλαπλασιάζεται (το πλάνο), εξοικονομήστε εκεί όπου πηγαίνουν τα tokens (τα build tickets). Σε ένα πραγματικό project 35 tickets τα build tickets χρησιμοποίησαν περίπου τα δύο τρίτα όλων των tokens, το verify περίπου ένα δέκατο, το plan + replan περίπου ένα έβδομο, οι peers 2%. Τα περισσότερα tokens είναι το context που ξαναδιαβάζεται σε κάθε βήμα, όχι η σκέψη — οπότε μετρούν περισσότερο το μοντέλο ανά build ticket και ο αριθμός των βημάτων· το think mode αγοράζει βάθος και κοστίζει σε ταχύτητα.

Master μόνο όταν το ζητήσετε (κοστίζει πολλά tokens): δύο seniors διαφορετικών οικογενειών — ο planner και ο peer του — που το εξετάζουν μαζί, το πολύ με τρεις ανταλλαγές, φτάνουν σε καλό πλάνο. Μπορείτε να παρακάμψετε οποιονδήποτε ρόλο, στο project ή σε ένα μεμονωμένο ticket.

Δυσκολία — κρίνεται από σήματα, ποτέ από αίσθηση:

Ένα μέρος που απέτυχε πριν ανεβαίνει ένα βήμα· το strategy eco ένα βήμα κάτω (ποτέ για Δύσκολη), το performance ένα βήμα πάνω. Ο ίδιος ρόλος δεν σημαίνει την ίδια ικανότητα παντού: διαβάστε το smart_weight στο codehero_get_providers_info — ο junior της Anthropic (Sonnet 5, βάρος 9) μπορεί να πάρει μέτρια δουλειά, ο junior της OpenAI (gpt-6-luna, βάρος 7) μόνο τετριμμένη και απλή δουλειά.

Ανάθεση providers (ποτέ δουλειά του Spec Builder):

• tickets οπτικής κατασκευής ή επαλήθευσης → μόνο providers με vision·
• τα chain tickets ([PLAN], [PEER], [VERIFY], [HELPER], [REPLAN]) → το προτιμώμενο ζεύγος είναι anthropic ↔ openai: η μία πλευρά σχεδιάζει και χτίζει, η άλλη κάνει review και επαληθεύει· μια εγκατάσταση χωρίς αυτούς χρησιμοποιεί τον provider master επιπέδου του πελάτη (υψηλότερο smart weight για master_developer), με διαφορετική οικογένεια για το verify όταν υπάρχει· οι ρητές προτιμήσεις του χρήστη υπερισχύουν·
• tickets [VERIFY] → διαφορετική οικογένεια providers από τον builder, senior_developer, balanced, basic για τετριμμένο/απλό γονικό, pro μόνο για πολύ κρίσιμο γονικό· εφαρμόστε τους ζωντανούς περιορισμούς providers και ledger·
• tickets που μοιράζονται sequence_order (μια εγκεκριμένη παράλληλη ομάδα) → κατανέμονται σε providers για να αποφεύγονται τα rate limits·
• strategy: eco = ο φθηνότερος ικανός, performance = υψηλότερο smart weight, balanced = και τα δύο·
• Ένας ενεργός provider μπορεί να χρησιμοποιηθεί μόνο για δουλειά για την οποία είναι επιλέξιμος και ικανός. Providers χωρίς vision δεν παίρνουν οπτική δουλειά. Σε ένα project με change ledger, οι αποκλεισμένοι (excluded) ρόλοι δεν μπορούν να κάνουν build/fix και οι ρόλοι με περιορισμό verify χρειάζονται έναν επικυρωμένο verifier Anthropic/OpenAI άλλης οικογένειας μετά την τελευταία τους αλλαγή. Αν δεν είναι διαθέσιμος, επιλέξτε έναν επιλέξιμο επικυρωμένο builder ή περιμένετε την απόφαση του χρήστη. Σε άλλες περιπτώσεις, η επαλήθευση από τον ίδιο provider σημειώνεται ως τέτοια και δεν αποτελεί γνώμη ανεξάρτητης οικογένειας.

4.5 Μετάφραση του environment contract σε project

4.6 Τα πεδία του ticket και τι κάνει με αυτά ο scheduler

Ο κανονικός χρονοπρογραμματισμός εξετάζει τη χαμηλότερη ανολοκλήρωτη σειρά και ξεκινά ανοιχτά tickets των οποίων οι εξαρτήσεις και το γονικό είναι done/skipped, ανάλογα με τις ρυθμισμένες θέσεις. Οι μεγαλύτερες κανονικές σειρές περιμένουν μέχρι όλα τα μικρότερα tickets να είναι done/skipped. Η ρητή εξαναγκασμένη εκκίνηση είναι ξεχωριστή εξαίρεση: αγνοεί σειρά, εξαρτήσεις, γονικό και όρια θέσεων και κρατά τη σημαία της μέχρι να καθαριστεί.

Οι τίτλοι είναι αφορμές. Τα [PLAN], [REPLAN], [VERIFY], [FIX], [HELPER], [PEER], [WORKER], [RELEASE] κάνουν τον daemon να προφορτώνει τον αντίστοιχο οδηγό στο context του ticket. Κρατήστε το πρόθεμα ακριβώς.

Προσθήκη tickets σε project που ήδη έχει: οι ρητοί αριθμοί σειράς σε μαζική κλήση μετατοπίζονται αυτόματα ώστε να συνεχίζουν μετά τα υπάρχοντα· το codehero_create_ticket αποθηκεύει τον αριθμό που δίνετε — έτσι ένας verifier βάζει τη διόρθωσή του στη δική του σειρά.

4.7 Πρώτα σειριακά· εγκεκριμένα παράλληλα με ανάλυση ιδιοκτησίας

Σχεδιάστε κάθε πλάνο σειριακά. Μια σειριακή εκτέλεση δεν μπορεί να καταστρέψει κοινά αρχεία, και κάθε ticket ξεκινά από την επαληθευμένη, αναφερμένη κατάσταση του προηγούμενου ticket. Το κόστος είναι ο χρόνος· το όφελος είναι η ορθότητα και ένα καθαρό ίχνος ελέγχου.

Σεβαστείτε το run contract. Το serial-only μένει σειριακό χωρίς προτάσεις παραλληλισμού. Όταν ο χρήστης έχει ζητήσει παράλληλη δουλειά (allowed-with-ownership-analysis), το planning ticket αποδεικνύει ακριβή, μη επικαλυπτόμενη ιδιοκτησία πριν μοιραστεί έναν αριθμό σειράς. Οι απαιτούμενες εξαιρέσεις helper/peer/fix/lead mode ακολουθούν τους οδηγούς τους.

1. Για κάθε ticket της ομάδας, καταγράψτε τα ακριβή αρχεία και φακέλους που θα δημιουργήσει ή θα επεξεργαστεί. Το ticket τα κατέχει (owns)· η λίστα μπαίνει στην περιγραφή του· ο agent δεν μπορεί να αγγίξει αρχεία εκτός αυτής (global H6).
2. Ελέγξτε τα επικίνδυνα αρχεία ονομαστικά απέναντι σε κάθε ticket της ομάδας: index.php / index.html, app.js / main.*, πίνακες routing, package.json / composer.json / requirements.txt, .env / config, DB migrations, global CSS, κοινά includes header/footer.
3. Απαιτείται μηδενική επικάλυψη. Οποιαδήποτε επικάλυψη → σειριοποίηση (depends_on + διαφορετικό sequence_order), διαχωρισμός της ιδιοκτησίας ή συγχώνευση σε ένα ticket.
4. Δείξτε τον πίνακα ιδιοκτησίας στο preview. Δείξτε την ανάλυση ιδιοκτησίας και σεβαστείτε το ρυθμισμένο όριο ταυτοχρονισμού ανά project (προεπιλογή εγκατάστασης 5)· το όριο δεν είναι άδεια για παραλληλισμό σε κοινά αρχεία. Σε οποιαδήποτε αμφιβολία → σειριακά.

Τρεις εξαιρέσεις δεν χρειάζονται έγκριση: τα tickets [VERIFY], [PEER] και [HELPER] μπορούν να μοιράζονται sequence_order με το ticket που εξυπηρετούν, επειδή απαγορεύεται να γράφουν αρχεία του προϊόντος· τα tickets [FIX] που δημιουργεί ένας verifier στη δική του σειρά ενώ σταθμεύει και τα περιμένει (§5.9)· και τα tickets [WORKER] του lead mode.

Lead mode — ο planner κρατά τον έλεγχο. Αφού ο planner και ο peer του συμφωνήσουν και έρθουν οι απαντήσεις σας, ένα ticket [PLAN] / [REPLAN] μπορεί να χτίσει το ίδιο 2–5 στενά συνδεδεμένα μέρη ως επικεφαλής (lead), αντί να τα δώσει σε κανονικά tickets, όταν έχει σημασία να κρατήσει το δικό του context (planning.md §2b). Γράφει πρώτα κάθε κοινό αρχείο (contracts, routes, config, migrations, αρχεία πακέτων, το πλάνο), μετά ανοίγει ένα [WORKER] ανά μέρος στη δική του σειρά: το καθένα με διαφορετική δουλειά, δικό του SPEC FILE, δικό του LOG (.specs/<NNN>-<part>.log) και μια γραμμή OWNS: που καταγράφει τα αρχεία του. Η πλατφόρμα αρνείται το εργαλείο επεξεργασίας αρχείων ενός worker έξω από αυτή τη γραμμή, οπότε κανένας worker δεν γράφει κοινό αρχείο ή αρχείο άλλου worker. Ο lead σταθμεύει με ⏸ WAITING-FOR-ALL-TICKETS #a, #b, … και ξυπνά μία φορά, όταν κάθε worker έχει απαντήσει ή τελειώσει· διαβάζει κάθε LOG, τρέχει την ομάδα tests κάθε worker, ελέγχει ότι άλλαξαν μόνο αρχεία που τους ανήκουν και κλείνει τους workers. Μια μακριά φάση μένει φθηνότερη και πιο στιβαρή ως κανονικά tickets + [VERIFY] + [REPLAN]: κάθε αναφορά ξυπνά τον lead και εκείνος ξαναδιαβάζει όλη τη συνομιλία του.

4.8 Η συνταγή περιγραφής ticket (κάθε ticket, και στις δύο λειτουργίες)

Κάθε native ticket εργασίας περιέχει: στόχο και IDs απαιτήσεων· το πραγματικό path του SPEC FILE του· ακριβή αρχεία προς ανάγνωση πρώτα και αρχεία που του ανήκουν· αναφορές σε έγκυρες ενότητες/εκδόσεις contracts· πραγματικά στοιχεία περιβάλλοντος και αναφορών σε secrets· παραδείγματα αποδοχής και αρνητικές περιπτώσεις· τις εντολές της δικής του ομάδας tests και των ομάδων που επηρεάζονται· γνωστές αποφάσεις/παγίδες· και τις απαιτούμενες ενότητες οδηγών πριν από το υλικό της προδιαγραφής. Μην επινοείτε paths αποθετηρίου σε υποψήφιο πακέτο. Χωρίς ονόματα containers/εσωτερικές IP, τιμές secrets ή αντιγραμμένη μέθοδο λειτουργίας της πλατφόρμας.

4.9 Execution mode και ροή

Το execution mode ελέγχει την έγκριση εργαλείων, όχι την άδεια να αγνοηθεί η ροή εργασίας. Οι agents των tickets χρησιμοποιούν τα εργαλεία snapshot/git της πλατφόρμας, ποτέ σκέτο git. Η αυτόνομη λειτουργία δεν εξουσιοδοτεί διαγραφή δεδομένων του project, παράκαμψη της έγκρισης υπηρεσιών, επινόηση επιχειρησιακών αποφάσεων ή αγνόηση της επιλεγμένης ροής ticket.

Προσέξτε τι δεν κάνει το relaxed: δεν επιτρέπει σε ένα ticket σε awaiting_input να ικανοποιήσει μια εξάρτηση. Οι εξαρτήσεις απαιτούν πάντα done ή skipped.

4.10 Τα δύο previews

Το preview του assistant (πριν υπάρξει οτιδήποτε):

⚙️ Settings
• Project: <name> (<type>, <path>) — <stack> · Environment: <deployment_mode> [services: …]
• Execution: <approved mode> · Flow: <relaxed → true | strict → false> · Strategy: <eco|balanced|performance>
• Pace: <standard|fast|ultra-fast> · Parallel: <serial-only|allowed-with-ownership-analysis>
• Plan approval: <autonomous|owner-approves-first-stage> · Releases: <none|at-milestones|every-phase>
• Planning ticket: <provider> · senior_developer (master only if you ask) · <balanced; pro only for a very critical core or documented failure escalation>

📄 Specification — <readiness state> · review: <what was actually done>
• Scope (MVP): … · Later / parked: … · Assumptions I made: … · Open items: <item → owner → what it blocks>
• Day-0 inputs you must provide: <what → who → when it is needed>

▶️ What happens after you confirm: project [+ environment] + ONE planning ticket …
Do you agree? (yes / no / changes)

Το πλάνο του planning ticket (στην τελική του αναφορά και στο αρχείο φάσης .specs/phases/K01.md — το αρχείο πλάνου .specs/001-project-plan.md μένει ένα μικρό ευρετήριο απαιτήσεων, ρυθμίσεων, ανοιχτών ερωτήσεων και φάσεων, τα παραδείγματα αποδοχής βρίσκονται στο .specs/001-acceptance.md, και το baseline παίρνει το .specs/000-baseline-index.md, ώστε τα μεταγενέστερα tickets να διαβάζουν μόνο τα μέρη που χρειάζονται): οι ρυθμίσεις εκτέλεσης σε μία γραμμή, μετά ο πίνακας tickets (# · ticket · seq · provider · role · think · deps · files owned · verify), συν τρεις έντιμες γραμμές — τι βρήκε το dry run, τι άλλαξαν οι γύροι review και πόσοι πράγματι έτρεξαν, και η ετυμηγορία του peer (ή «no second provider»). Η δημιουργία φάσης απαιτεί native_creation_authorized=true και plan_approval=autonomous στο δικό του RUN CONTRACT ανώτατου επιπέδου του ticket, συν ικανοποιημένες πύλες scope/δεδομένων/υπηρεσιών και κλειστούς helpers review. Η σημαία ενός συνημμένου δεν είναι εξουσιοδότηση. Με owner-approves-first-stage, ή χωρίς ρητή native εξουσιοδότηση, δείξτε το πλάνο και περιμένετε πριν δημιουργήσετε tickets εργασίας.

Διαβάστε ένα πλάνο σαν reviewer, όχι σαν θεατής: είναι το πρώτο ορόσημο το λεπτότερο end-to-end κομμάτι; Χρησιμοποιεί κάθε [VERIFY] διαφορετική οικογένεια providers; Είναι κάθε οπτικό ticket σε provider με vision; Εκφράζει κάθε εξάρτηση μια πραγματική ανάγκη; Υπάρχει μέσα κάτι που δεν ζήτησε κανείς;

4.11 Περίγραμμα φάσης στην πράξη: RepairFlow

Αυτό είναι ενδεικτικό περίγραμμα για το planning ticket, όχι μαζικό πλάνο που θα δημιουργήσει ο assistant. Υποθέστε ότι το ενεργό scope και οι επιχειρησιακές του αποφάσεις είναι επιβεβαιωμένα· καταγράψτε τα R IDs τους και την πραγματική απόδειξη δυνατοτήτων. Διαβάστε τους ζωντανούς providers και την επιλεξιμότητα ledger ανά ρόλο πριν αναθέσετε οποιαδήποτε γραμμή.

1. SETUP: αποδείξτε την ετοιμότητα runtime/βάσης δεδομένων/preview και καλύψτε μόνο εγκεκριμένα κενά περιβάλλοντος· ρυθμίστε τα θεμέλια της εφαρμογής.
2. Πύλη πρόσβασης: υλοποιήστε και επαληθεύστε το μικρότερο επιβεβαιωμένο κομμάτι login/προστατευμένης ροής, συμπεριλαμβανομένων των αρνήσεων και της διαδικασίας διαχειριστή υπό τον έλεγχο του operator.
3. Βασικό κομμάτι: δημιουργία εργασίας, εκτέλεση της επιβεβαιωμένης μετάβασης κατάστασής της και παράδοσή της· συμπεριλάβετε τη βοήθεια εκείνου του ρόλου, επαναλήψιμα tests και παραδείγματα αποδοχής.
4. Συμπεριφορά/ειδοποίηση εκπρόθεσμων μόνο όταν έχουν επιβεβαιωθεί η σημασία της προθεσμίας, οι παραλήπτες, η συχνότητα και τα δικαιώματα.
5. Προσθέστε τα απαιτούμενα επεισόδια ανεξάρτητης επαλήθευσης ανάλογα με τον κίνδυνο, τον ρυθμό και τους περιορισμούς providers· κάθε οπτική δουλειά χρησιμοποιεί provider με vision.
6. Κλείστε τη φάση με REPLAN: πλήρης εκτέλεση tests της φάσης, σύγκριση baseline-συν-ledger και το επόμενο στάδιο ή η τελική αποδοχή.

Το PLAN καταγράφει το ίδιο την αρχική γνώση· δεν υπάρχει υποχρεωτικό ξεχωριστό ticket θεμελίωσης γνώσης. Η δουλειά setup/πυρήνα χρησιμοποιεί junior + balanced όταν είναι μέτρια· η δύσκολη δουλειά authentication/ταυτοχρονισμού χρησιμοποιεί senior + balanced, pro μόνο για πολύ κρίσιμο πυρήνα. Τα VERIFY και REPLAN κανονικά χρησιμοποιούν senior + balanced. Οι αριθμοί και η ακριβής σειρά καθορίζονται στην πραγματική εγκατάσταση.

4.12 Δύο περιγραφές tickets από εκείνο το πλάνο

Ticket 3 — Ρύθμιση εφαρμογής (junior_developer, balanced — Μέτρια):

Objective (R001, R010, R011): create the application foundation for RepairFlow.
- includes/config.php: the canonical bootstrap (env → session → PDO → CSRF → helpers → error handler)
  exactly as the project context prescribes. Read DB_* from .env; commit .env.example only.
- database/schema.sql: tables customers, technicians, jobs, job_status_history, job_helpers,
  users (roles: owner, front_desk, technician). Money = DECIMAL(10,2). Every table has id,
  created_at, updated_at; FKs indexed; ON UPDATE CASCADE everywhere; job_status_history keeps
  who/when/from/to (no silent overwrite).
- Create the non-secret seed records needed by the acceptance examples. The login-delivering ticket
  owns test-account setup. Store long-lived test credentials only through the approved secrets
  procedure and use references; never write passwords in .specs, reports, tickets or knowledge. A
  one-check disposable account may appear only in the approved Browser/HttpRequest call and must be
  revoked immediately afterward.
- includes/header.php + includes/footer.php with the shared navbar (relative links only),
  libs/ copied from /opt/codehero/libs (tailwind, alpine, fontawesome with webfonts).

Owned files: includes/, database/, libs/, webfonts/, .env.example, .specs/003-setup.md

Contracts other tickets rely on:
- jobs.status ENUM('received','in_repair','ready','delivered')
- jobs.deadline DATE = received_at + 14 days (computed on insert by JobService, never by the UI)
- helper functions e(), csrf_field(), csrf_check(), requireAuth(?string $role)

Environment: MySQL at localhost:3306, credentials in the PROJECT DATABASE block.
Preview URL: https://127.0.0.1:{PROJECTS_PORT}/repairflow/

Definition of done:
- php -l passes on every file; schema.sql applied without error; seed rows present (SELECT COUNT).
- Loading the preview URL returns the header/footer skeleton with 0 console errors and 0 requests ≥ 400.
- .specs/003-setup.md acceptance list walked item by item; knowledge stored: schema decisions,
  status enum, deadline rule (type: decision) with WHY.

Ticket 4 — [VERIFY] Ρύθμιση εφαρμογής (διαφορετική οικογένεια providers, senior_developer, balanced, parent_sequence = 3, ώστε η πλατφόρμα να του δώσει parent_ticket_id και να το κάνει να περιμένει το ticket 3· το guides/verify-fix.md προφορτώνεται):

cycle 1 · GUIDE: verify-fix.md
You only CHECK. You never edit code and never "improve" anything.
Parent: your parent_ticket_id (codehero_get_ticket on your own id). Its SPEC FILE: .specs/003-setup.md.

Walk the parent's ACCEPTANCE list item by item, run the CORE Section 9 recipe on the preview URL
and the parent's tests (`bash .tests/run.sh 003`). Add your own negative checks: a page without the bootstrap must not exist;
the DB DSN must include charset=utf8mb4; PDO must use ERRMODE_EXCEPTION; a second run of schema.sql
must fail cleanly, not corrupt data; no absolute URLs in header/footer.

A FINDING = a requirement not met or a reproducible bug, with steps, expected, observed.
Style preferences are not findings (one line at the end at most).
No findings → VERIFY: PASS line on the parent's SPEC FILE, report "verified: pass" with evidence.
Findings → create [FIX] tickets for the original builder at YOUR sequence_order — one per finding, or per
small group in the same place, at most 5 (ticket 3's provider; cycle 1 = its role and think mode, then the fix ladder;
no depends_on on you), park with ⏸ WAITING-FOR-ALL-TICKETS #<fix ids>, and re-check the findings yourself when the
fixes reply (cycle 2). Circuit breaker after 3 cycles.

4.13 Μετά τη δημιουργία

Χρησιμοποιήστε το codehero_get_project_progress (ή τη σελίδα Project Progress) για να δείτε τα tickets με τους ρόλους και τους providers τους· το codehero_update_ticket για να αλλάξετε τον ρόλο, τον provider, το think mode ή την κατάσταση ενός ticket· το codehero_set_ticket_sequence για αναδιάταξη. Ο agent θα δημιουργήσει τα δικά του tickets VERIFY, fix, helper και replan κατά την εκτέλεση — περιμένετε να μεγαλώσει η λίστα, και ελέγξτε ότι κάθε νέο ticket ακολουθεί τους ίδιους κανόνες (Ενότητα 5).

Ασκήσεις — Ενότητα 4

1. Εισαγάγετε το πακέτο από την άσκηση της Ενότητας 2 στο Plan with AI. Πριν πείτε ναι, γράψτε τρία πράγματα που θα αλλάζατε στο preview και γιατί. Εφαρμόστε τα με «changes», μετά επιβεβαιώστε.
2. Γράψτε την πλήρη περιγραφή πέντε μερών για το ticket 7 του πλάνου RepairFlow (το βασικό κομμάτι), συμπεριλαμβανομένων των contracts στα οποία θα βασιστεί το ticket των εκπρόθεσμων.
3. Ο planner προτείνει να τρέξουν παράλληλα τα «Customer list page» και «Technician list page». Κάντε την ανάλυση ιδιοκτησίας αρχείων: καταγράψτε τα αρχεία κάθε ticket, ελέγξτε τα επικίνδυνα αρχεία, αποφασίστε. Δείξτε τον πίνακα ιδιοκτησίας.
4. Εξηγήστε, με τους κανόνες του scheduler της §4.6, τι συμβαίνει στο ticket 9 αν το ticket 7 τελειώσει σε awaiting_input με ερώτηση. Τι πρέπει να κάνει ο operator;
5. Ένας συνάδελφος σας δίνει μια παρτίδα όπου το ticket 1 έχει depends_on: [1]. Τι συμβαίνει όταν υποβληθεί, και πώς το διορθώνετε;

---

ΜΕΡΟΣ V — ΕΚΤΕΛΕΣΗ

Ενότητα 5 — Τι συμβαίνει όταν τρέχει ένα ticket, και πώς να το διαβάσετε

5.1 Ο κύκλος ζωής ενός ticket

            ┌──────────── retry (≤ max_retries, cooldown) ────────────┐
            │                                                          │
 open ──► in_progress ──► agent says TASK COMPLETED ──► awaiting_input ──► done
   ▲            │                                     (reason: completed | question | error | permission | stopped)
   │            │ crash / exception                           │
   │            ▼                                             │ relaxed: auto-reviewer says COMPLETED
   │         failed ───────── past max_retries ──► failed (sticks)      │ strict: a human closes
   │            │                                             │
   │            └── rate limited ──► open (after cooldown, not counted as a failure)
   │
   └──────── user or peer reply, "Retry", "Reopen" ──── awaiting_input   (a reply re-opens; a parked ticket whose
                                                   awaited ticket ended without replying is woken by a watchdog)

 stuck   = the watchdog judged the conversation an unproductive loop
 timeout = max_duration_minutes exceeded
 skipped = manual skip; counts as complete for dependencies (timeout does not)

Γεγονότα στα οποία θα βασίζεστε:

• Ο agent δεν γράφει ποτέ ο ίδιος done. Η ολοκλήρωση πάντα σταθμεύει το ticket σε awaiting_input με μια αιτία· το κλείσιμο είναι απόφαση review (αυτόματη σε relaxed λειτουργία, ανθρώπινη σε strict).
• Οι αναφορές ξεκινούν με NEEDS THE USER: yes|no και OPEN ISSUES AND DOUBTS: ...|none. Κεφαλίδες που λείπουν ή είναι αντιφατικές επιστρέφονται μία φορά για διόρθωση· μια δεύτερη αντίφαση περιμένει τον χρήστη. Τα tickets peer/helper/worker τα κλείνει αυτός που τα άνοιξε, όχι ο auto-reviewer. Μια ζωντανή εξάρτηση στάθμευσης κρατά τον κάτοχό της σταθμευμένο. Ακολουθήστε τα γεγονότα του scheduler στο ASSISTANT_CLAUDE.md.
• Οι κανονικές απαντήσεις ξυπνούν τα σταθμευμένα tickets και φτάνουν στα tickets που τρέχουν στο επόμενο βήμα τους. Το wake=false είναι μόνο πληροφοριακό και δεν ξυπνά κανέναν. Μια απάντηση σε ολοκληρωμένο ticket μπορεί να το ξανανοίξει· μη στέλνετε εκεί ειδοποιήσεις αλλαγών.
• Οι εξαρτήσεις χρειάζονται done ή skipped. Ένα ticket που κάθεται σε awaiting_input μπλοκάρει ό,τι εξαρτάται από αυτό. Σε σειριακό πλάνο αυτό σημαίνει ότι όλο το project περιμένει την απάντησή σας — σκόπιμα.
• Retries: ένα crash ή σφάλμα provider επιστρέφει το ticket σε open έως max_retries (προεπιλογή 3) με cooldown· ένα rate limit δεν είναι αποτυχία. Ένα όριο χρήσης subscription σταθμεύει το ticket μέχρι να μηδενιστεί το όριο (μία ειδοποίηση, ένας έλεγχος το πολύ κάθε 30 λεπτά, κανένα retry δεν μετριέται), και μια επανεκκίνηση του daemon ή μια αναβάθμιση δεν καταναλώνει ποτέ retry. Ένα ticket που σταματήσατε με το kill switch δεν αντικαθίσταται ποτέ με failed.
• Ο watchdog ελέγχει τα tickets που τρέχουν πολύ ώρα και ρωτά έναν sub-agent αν η συνομιλία έχει πράγματι κολλήσει· η οδηγία προς αυτόν τον sub-agent είναι σε αμφιβολία, να συνεχίζει. Οι πραγματικοί βρόχοι γίνονται stuck.

5.2 Τι βλέπει και τι μπορεί να κάνει ο agent

Το system prompt είναι η πολυεπίπεδη σύνθεση της Ενότητας 1 §1.6. Πάνω σε αυτό ο agent έχει δύο οικογένειες εργαλείων:

Ενσωματωμένα εργαλεία (HeroAgent) — με την πολιτική που διδάσκει στο μοντέλο το δικό τους σύντομο σημείωμα χρήσης:

Εργαλεία πλατφόρμας (MCP, codehero_*) — αυτά που το global context κάνει υποχρεωτικά: codehero_knowledge_search / codehero_knowledge_store / codehero_knowledge_list (η knowledge base), codehero_git_operations (backup_snapshot, backup_status, backup_restore, …), codehero_screenshot, codehero_extract_context, codehero_get_guide (ανοίγει έναν από τους δεκαπέντε οδηγούς κατ' απαίτηση), τα εργαλεία αναζήτησης codehero_search_tickets (ακριβείς λέξεις στα tickets του project), codehero_codebase_query (πού ορίζεται μια συνάρτηση ή κλάση, με τις γραμμές της· ποιος την καλεί — όταν το Codebase Map είναι ενεργό) και codehero_semantic_search (αποφάσεις, μηνύματα, προδιαγραφές και κώδικας με βάση το νόημα, στα ελληνικά ή στα αγγλικά — όταν η σημασιολογική αναζήτηση είναι ενεργή), και τα εργαλεία tickets codehero_get_ticket / codehero_update_ticket (απάντηση, κλείσιμο) / codehero_create_ticket / codehero_get_project_progress / codehero_start_ticket (εξαναγκασμένη εκκίνηση). Κάθε αποτέλεσμα MCP ενός agent ticket φέρει επίσης τα μηνύματα που του έγραψαν άλλα tickets όσο δούλευε. Χρησιμοποιήστε τον χάρτη κώδικα και το σημασιολογικό ευρετήριο όταν είναι διαθέσιμα· χειριστείτε τα αποτελέσματα που λείπουν ή είναι παρωχημένα με τις εναλλακτικές περιορισμένης αναζήτησης/ανάγνωσης του πυρήνα. Μη θεωρείτε τη φρεσκάδα του ευρετηρίου απόδειξη ότι ένα αρχείο ή μια αλλαγή δεν υπάρχει.

Το permission hook βρίσκεται ανάμεσα στο μοντέλο και σε κάθε κλήση εργαλείου. Επιβάλλει το execution mode (Ενότητα 4 §4.9), την προστασία paths (H5: ακολουθήστε τα επιτρεπόμενα paths του project και το CONTAINER EXECUTION CONTEXT· κάθε επιτρεπόμενος πρόσθετος χώρος εργασίας είναι μέσα στο container, ποτέ στον host· τα προσωρινά αρχεία ανήκουν στο .tmp/ του project και ο πηγαίος κώδικας προσαρμοσμένων υπηρεσιών στο .services/ του· η δρομολόγηση σε container δεν δίνει άδεια για απευθείας επεξεργασία προστατευμένων αρχείων συστήματος/πλατφόρμας, του nginx ή του /opt/services), τη γραμμή OWNS: ενός [WORKER], τη δρομολόγηση σε container (μια εντολή που θα έτρεχε στον host αντί μέσω crun απορρίπτεται με την αιτία, ποτέ δεν μετατρέπεται σε ερώτηση προς εσάς), την απόρριψη του Bash στο παρασκήνιο, τη φύλαξη από κακοσχηματισμένες επεξεργασίες, και την ανίχνευση βρόχων: μια πανομοιότυπη ενέργεια που επαναλαμβάνεται τρεις φορές επιστρέφει στο μοντέλο ένα μήνυμα «you appear to be stuck — stop and rethink»· στις πέντε σταματά οριστικά την προσέγγιση. Η αναμονή μόνο για ανάγνωση εξαιρείται — polling ενός ticket, ένα σκέτο sleep, status του ProcessManager, LogTail, ή επανανάγνωση ενός log που μεγαλώνει με tail / ls / ps (και μέσω crun) — ώστε η αναμονή για μια μακριά εκτέλεση tests ή για έναν σταθμευμένο διάλογο να μη θεωρείται βρόχος· η επανανάγνωση του ίδιου αρχείου με cat / grep εξακολουθεί να θεωρείται. Στο Codex, η αιτία κάθε άρνησης παραδίδεται μέσα στη σειρά που τρέχει, ώστε το μοντέλο να μαθαίνει το γιατί αντί να βλέπει μόνο «declined». Ο HeroAgent προσθέτει μετρητές σφαλμάτων ανά εργαλείο (προειδοποίηση σε τρεις διαδοχικές αποτυχίες, διακοπή στις πέντε) και ανώτατο όριο 1000 επαναλήψεων ανά εκτέλεση.

Διατηρήστε το εγκεκριμένο environment_contract στην προδιαγραφή. Οι οδηγίες των tickets περιγράφουν το πραγματικό περιβάλλον εκτέλεσης του project, τα paths του project, τα ports των τοπικών υπηρεσιών και τις αναφορές σε secrets· παραλείπουν ονόματα containers, εσωτερικές IP containers και εντολές εισόδου από την πλευρά του host. Οι υπηρεσίες στο ίδιο μηχάνημα χρησιμοποιούν localhost:<verified port>· οι εξωτερικές υπηρεσίες κρατούν τα πραγματικά τους endpoints. Οι έλεγχοι σε browser χρησιμοποιούν το preview URL της πλατφόρμας.

Μετά την έγκριση, δημιουργήστε μέσω MCP το project και το δηλωμένο platform container και το περιβάλλον του καταλόγου πριν από το planning ticket. Το nginx είναι ενσωματωμένο και δεν δηλώνεται ποτέ ως πρόσθετη υπηρεσία. Το planning ticket μπορεί να ανακαλύψει ένα εγκεκριμένο κενό υπηρεσίας: το SETUP ticket του μπορεί να το εγκαταστήσει ή να το καταχωρίσει μέσα στο container του project σύμφωνα με το GUIDE: services.md. Τα runtimes του host που λείπουν είναι δεδομένα με υπεύθυνο τον operator· τα tickets δεν τα εγκαθιστούν.

Η καταστροφή, η μετεγκατάσταση, η διακοπή του container και η επαναφορά ή διαγραφή ενός snapshot απαιτούν το ρητό ναι του χρήστη για τη συγκεκριμένη ενέργεια. Για τις υποστηριζόμενες ενέργειες container, περάστε user_confirmed=true μόνο μετά από εκείνο το ναι. Μην επινοείτε ποτέ ενέργεια δικτύου ή παράμετρο που δεν υπάρχει στο ζωντανό schema.

5.3 Ο βρόχος εργασίας που ακολουθεί ο agent (global §5)

1. Κατανοεί την εργασία (εφαρμόζει τον κανόνα γλώσσας).
2. Αναζητά στη knowledge base — ένα ευρύ ερώτημα με τον τίτλο της εργασίας, ένα ανά component — και μετά διαβάζει τον σχετικό κώδικα.
3. Ανοίγει το SPEC FILE (.specs/<NNN>-<task>.md), πάντα, ακόμη και για εύκολη εργασία: GOAL και STATUS πριν από οποιονδήποτε κώδικα. Ανοιχτές ερωτήσεις → ρωτά τώρα, σε μία δέσμη, ή εφαρμόζει ασφαλή προεπιλογή. (Μια μικρή αλλαγή ή διόρθωση — ένα συγκεκριμένο πράγμα, χωρίς νέα σελίδα, πίνακα ή λειτουργία — τρέχει τον ελαφρύ βρόχο: ένα SPEC FILE δύο γραμμών, μόνο τον οδηγό του πράγματος που αγγίζεται, επαλήθευση εκείνου του πράγματος, εκτέλεση της δικής του ομάδας tests και των ομάδων που επηρεάζονται, snapshot, μια αναφορά πέντε γραμμών. Χωρίς plan mode, χωρίς γύρους, χωρίς peer.)
4. Χτίζει ένα μικρό μέρος.
5. Επαληθεύει εκείνο το μέρος (§5.5). Αποτυγχάνει → πρωτόκολλο debugging (§5.6).
6. Ενημερώνει το SPEC FILE, μετά snapshot. Μετά από κάθε μέρος, όχι μόνο στο τέλος.
7. Μένουν μέρη → πίσω στο 4.
8. Ελέγχει την πραγματική ροή που άλλαξε στο PREVIEW URL, τρέχει τα δικά του tests και τις ομάδες που επηρεάζονται από την αλλαγή, και μετά καταγράφει κάθε στοιχείο ACCEPTANCE ως pass, fail ή BLOCKED με απόδειξη. Το VERIFY τρέχει τις ομάδες των γονικών του και τους δικούς του αρνητικούς ελέγχους. Η πλήρης σουίτα της φάσης ανήκει στο REPLAN, ή σε ρητό αίτημα του χρήστη· η διάρκεια δεν είναι το κριτήριο επιλογής ομάδων.
9. Αποθηκεύει γνώση: αποφάσεις και προσεγγίσεις που απέτυχαν.
10. Αναφέρει — δύο γραμμές, μετά η παράδοση 4 μερών (§5.8), μετά TASK COMPLETED.

Μακριά εργασία; Μετά από ένα επαληθευμένο μέρος ο agent μπορεί να καλέσει το codehero_extract_context για να συμπιέσει παλιά μηνύματα· το SPEC FILE επιβιώνει της συμπίεσης και ξαναδιαβάζεται αμέσως μετά. Μετά από οποιοδήποτε compaction — του ίδιου του Claude CLI ή του Codex, του CodeHero μέσα σε μια εκτέλεση, ή ενός νέου γύρου χτισμένου από την περίληψη του CodeHero — ο agent παίρνει τον ίδιο κανόνα (4.65.9): η περίληψη και το STATUS του SPEC FILE είναι η κατάστασή του, δεν ξαναδιαβάζει ποτέ τα πάντα, και ένα κενό αναζητείται μόνο εκεί όπου βρίσκεται — στο ιστορικό του δικού του ticket (codehero_search_tickets με το id του), στον κώδικα (σημασιολογική αναζήτηση, χάρτης κώδικα, grep), στις αποφάσεις — και ένας οδηγός μόνο κατά την ΕΝΟΤΗΤΑ που χρειάζεται το επόμενο βήμα του (codehero_get_guide(name, section=…)). Η πλατφόρμα κάνει επίσης compaction αυτόματα όταν η συνομιλία ξεπεράσει τα όριά της, και δείχνει ένα ορατό μήνυμα compaction στο ticket. Γι' αυτό το P6 (μνήμη στον δίσκο) είναι αρχή και όχι πρόταση: ό,τι χρειάζεται το επόμενο βήμα πρέπει να βρίσκεται ήδη στο .specs/ ή στη knowledge base.

Από την 5.0.0, ένας agent ticket μπορεί να «διπλώνει» (fold) τα δικά του μεγάλα αποτελέσματα εργαλείων, κλήσεις ή μηνύματα με το codehero_fold και να ανακτά λεπτομέρειες που χρειάζεται με το codehero_unfold όταν το επιτρέπει το folding_enabled. Οι εικόνες δεν διπλώνονται: στα μοντέλα API ένα screenshot φαίνεται μία φορά και μετά αφαιρείται αυτόματα από το context (μένει μόνο η περιγραφή του από τον agent). Τα μοντέλα API εφαρμόζουν ένα fold στο επόμενο request τους· το Claude σε print mode, το Codex και το Grok Build στην επόμενη ανακατασκευασμένη εκτέλεσή τους· το διαδραστικό Claude όταν ανακατασκευάζεται η συνεδρία του. Ο απαιτούμενος συλλογισμός του μοντέλου διατηρείται από την πλατφόρμα ανάμεσα στις εκτελέσεις. Αυτό είναι διαχείριση μνήμης του agent ticket· οι assistants δεν το ρυθμίζουν ούτε το χειρίζονται για τα projects, και δεν είναι λόγος να αντιγραφούν βασικές οδηγίες στα overrides.

5.4 Δύο μνήμες

Κάθε failed_approach πρέπει να έχει ακμή failed_for προς το component που έβλαψε (όνομα component = όνομα αρχείου χωρίς επέκταση). Την επόμενη φορά που οποιοδήποτε ticket επεξεργαστεί εκείνο το αρχείο, βλέπει το αδιέξοδο. Μάθετε στους εκπαιδευόμενούς σας να ελέγχουν το graph μετά από μια εκτέλεση: ένα project με μηδέν κόμβους decision μετά από δέκα tickets είναι ένα project του οποίου οι agents δεν ακολουθούν την §7 — πρόβλημα context, όχι πρόβλημα μοντέλου. Με ενεργή τη σημασιολογική αναζήτηση, η αποθήκευση γνώσης πρώτα καταγράφει παρόμοιους υπάρχοντες κόμβους, ώστε ο agent να ενημερώνει εκείνον τον κόμβο αντί να προσθέτει διπλότυπο.

5.5 Η συνταγή επαλήθευσης (global §9) — τι σημαίνει συγκεκριμένα «απόδειξη»

• Έλεγχοι σύνταξης: php -l, python3 -m py_compile, node --check, tidy.
• Συνταγή browser στο PREVIEW URL: goto → δοκιμή των βασικών ενεργειών → console_logs (πρέπει 0 σφάλματα) → network_logs (καμία απρόσμενη απόκριση δικτύου >=400· ένα σκόπιμο 401/403/422 σε επίπεδο εφαρμογής περνά μόνο με τον αντίστοιχο εξουσιοδοτημένο θετικό έλεγχο και ρητή καταγραφή του αναμενόμενου αποτελέσματος· μια άρνηση από proxy/WAF δεν αποτελεί απόδειξη εξουσιοδότησης της εφαρμογής) → PageAssert (χωρίς σφάλματα console, χωρίς σπασμένες εικόνες, ορατά τα βασικά στοιχεία) → LogTail στα nginx-error και php-fpm-8.3.
• Αν το project έχει login: ελέγξτε την κατάσταση σύνδεσης (διαδρομή UI και διαδρομή API/CSRF) ΚΑΙ τις αρνήσεις με θετικό έλεγχο (guides/testing.md)· το ticket που παραδίδει το login δημιουργεί τον χρήστη tests.
• Οι αποστολές χρειάζονται απόδειξη: ένα email, webhook ή export έχει «σταλεί» μόνο με απόδειξη λήψης, μια γραμμή log, μια γραμμή outbox ή ένα δοκιμαστικό inbox. Αλλιώς «επιχειρήθηκε, ανεπιβεβαίωτο» ή BLOCKED.
• Τα αναμενόμενα αποτελέσματα έρχονται από έξω από τον κώδικα: το αίτημα, τη λίστα αποδοχής, τον χρήστη. «Η συνάρτηση επιστρέφει 42 και το test μου περιμένει 42 επειδή η συνάρτηση το επιστρέφει» δεν αποδεικνύει τίποτα.
• Κάθε διαδραστικό στοιχείο φέρει ένα data-testid ({action}-btn, {field}-input, nav-{page}, …) ώστε τα VERIFY tickets σε άλλους providers να μπορούν να το βρουν.

Κανόνες του preview URL που ο agent δεν πρέπει να «παρακάμπτει»: ένα 403 στο σκέτο root σημαίνει ότι λείπει ο φάκελος του project από το URL (auth ανά project, αναμενόμενο)· ένα 400 σε απλό http:// σημαίνει ότι το scheme είναι λάθος (είναι HTTPS). Κανένα από τα δύο δεν είναι bug· και τα δύο σημαίνουν «διορθώστε το URL και δοκιμάστε ξανά την ίδια μορφή». Ποτέ php -S, ποτέ άλλο port, ποτέ localhost αντί για 127.0.0.1.

5.6 Το πρωτόκολλο debugging (global §8 + guides/debugging.md)

Snapshot → αναπαραγωγή μία φορά → συλλογή αποδείξεων με σειρά (browser console, network ≥ 400, nginx-error, php-fpm, mysql-error) → εντοπισμός του πρώτου σημείου όπου η πραγματικότητα διαφέρει από την προσδοκία κατά μήκος request → handler → λογική → αποθήκευση → response → σελίδα → μία υπόθεση → ένας στοχευμένος έλεγχος → διόρθωση της γενεσιουργού αιτίας → επαλήθευση (επανάληψη της αναπαραγωγής, μετά η πλήρης συνταγή). Το πολύ πέντε υποθέσεις· μετά από πέντε: επαναφορά του snapshot αν τα πράγματα χειροτέρεψαν, επανανάγνωση του SPEC FILE, προαιρετικά άνοιγμα ενός HELPER ticket σε άλλον provider, μετά απλοποίηση στη μικρότερη εκδοχή που δουλεύει και προσθήκη κομματιών ξανά ένα-ένα.

Κανόνες που πιάνουν τα περισσότερα πραγματικά περιστατικά: ποτέ μην τρέχετε τον ίδιο αποτυχημένο έλεγχο δύο φορές ελπίζοντας σε διαφορετικό αποτέλεσμα (αυτός είναι ο βρόχος που ανιχνεύει το hook)· αλλάζετε ένα πράγμα τη φορά· ποτέ μην αποδυναμώνετε το WAF, το auth, το CSRF ή το validation για να περάσει — κάντε bisect στο payload και διορθώστε το request· ένας έλεγχος που ήταν πράσινος και τώρα είναι κόκκινος είναι regression και προηγείται στην ουρά· το «200 αλλά λάθος συμπεριφορά» είναι bug λογικής στον κώδικα του ίδιου του agent, όχι στο εργαλείο· και αν ο agent μπορεί να εξηγήσει γιατί ο κώδικας συμπεριφέρεται έτσι αλλά όχι ποια είναι η σωστή συμπεριφορά, αυτό είναι επιχειρησιακός κανόνας που λείπει → σταματήστε και ρωτήστε.

Ο πίνακας συμπτωμάτων στην §8 του global context (κενή σελίδα PHP → php -l + log php-fpm· 404 σε assets → απόλυτο URL· το login «δουλεύει» αλλά είστε αποσυνδεδεμένοι → εγγραφή/ανάγνωση session· η φόρμα υποβάλλεται, τίποτα δεν αποθηκεύεται → ασυμφωνία name=· το POST επιστρέφει 403/406 ενώ η σελίδα φορτώνει → κανόνας WAF, bisect στο payload) είναι το πρώτο πράγμα που πρέπει να διδάξετε σε έναν εκπαιδευόμενο που θα διαβάζει transcripts: οι περισσότερες «κολλημένες» εκτελέσεις είναι ένα από αυτά.

5.7 Όταν ο agent σταματά για να ρωτήσει — και πώς απαντάτε

Ο agent ρωτά μόνο για επιχειρησιακούς κανόνες (P3), καταστροφικές ενέργειες (H7), διαπιστευτήρια που λείπουν, ή την πύλη «να δημιουργήσω τα tickets;» στο PLAN MODE. Η μορφή είναι σταθερή (global §4.1): μία έως τρεις γραμμές για το τι κατάλαβε και τι αποφάσισε, μετά αριθμημένες ερωτήσεις με επιλογές και μια σύσταση, που απαντώνται ως «1A, 2B, 3 ναι». Πριν σας ρωτήσει, θα πρέπει να έχει φιλτράρει τις ερωτήσεις μέσω ενός HELPER ticket σε άλλον provider (P4) και να σας πει σε μία γραμμή τι ξεκαθάρισε ο helper.

Η δική σας πλευρά του πρωτοκόλλου:

1. Διαβάστε το τελευταίο μήνυμα του ticket στη σελίδα Ticket Detail (ή την ειδοποίηση Telegram).
2. Απαντήστε σε κάθε αριθμημένη ερώτηση σε μία απάντηση, με την ίδια αρίθμηση. Μην απαντάτε σε τεχνικές ερωτήσεις που θα έπρεπε να είχε αποφασίσει ο ίδιος ο agent — πείτε του να αποφασίσει («2: δική σας επιλογή, καταγράψτε την στο SPEC FILE»).
3. Αν η ερώτηση είναι επιχειρησιακός κανόνας που δεν ξέρετε, πάρτε την απάντηση από τον πελάτη και καταγράψτε την και στο Decision Log της προδιαγραφής· το πακέτο είναι η πηγή αλήθειας, όχι το chat.
4. Στείλτε. Το ticket ξανανοίγει· ο agent γράφει την απάντηση στο SPEC FILE και αποθηκεύει τους μόνιμους κανόνες στη knowledge base· δεν πρέπει να ξαναρωτήσει ποτέ ερώτηση που έχει απαντηθεί. Μια απάντηση που αλλάζει ή προσθέτει απαίτηση ακολουθεί το guides/update.md: μία γραμμή στο change ledger .specs/000-changes.md (το log που διαβάζει πρώτο κάθε ticket), ενημέρωση των ενεργών προδιαγραφών, contracts, tests και γνώσης, και μια πληροφοριακή ειδοποίηση σε κάθε ανολοκλήρωτο ticket που αγγίζει — δεν χρειάζεται ποτέ να επαναλάβετε την αλλαγή σε κάθε ticket.

Αν η ίδια ερώτηση επανέρχεται συνεχώς σε διάφορα tickets, η απάντηση δεν βρίσκεται στον δίσκο: ελέγξτε τη knowledge base και την περιγραφή του project, και διορθώστε αυτό αντί να απαντάτε ξανά.

5.8 Η αναφορά: δύο γραμμές, μετά τέσσερα μέρη

Κάθε ολοκληρωμένο ticket τελειώνει με μια αναφορά γραμμένη για εσάς και διαβασμένη από τον auto-reviewer. Ξεκινά με δύο γραμμές στα αγγλικά:

• NEEDS THE USER: yes — <what> ή NEEDS THE USER: no — το yes σημαίνει ότι τα επόμενα tickets πρέπει να σας περιμένουν: μια κρίσιμη ερώτηση, μια αμφιβολία για καταστροφική ενέργεια, μια έγκριση, ένα μέρος που απέτυχε ή μπλόκαρε και πάνω στο οποίο χτίζουν μεταγενέστερα tickets.
• OPEN ISSUES AND DOUBTS: <numbered list> ή none — ένα μέρος που απέτυχε, δεν μπόρεσε να επαληθευτεί, είναι μπλοκαρισμένο, ή ένα αποτέλεσμα για το οποίο ο agent δεν είναι σίγουρος. Ποτέ κρυμμένο για να κλείσει το ticket (αυτό είναι πλαστογράφηση ελέγχου), ποτέ επινοημένο (οι κενές επιφυλάξεις κρατούν το πλάνο χωρίς λόγο).

Μετά τέσσερα μέρη, με αυτή τη σειρά:

1. Τι δουλεύει τώρα — με την απόδειξη (ποιο test έτρεξε, ποιο URL φόρτωσε, ποιο screenshot).
2. Τι περιμένει τον χρήστη — μπλοκαρισμένα μέρη με το ακριβές αίτημα (διαπιστευτήρια, αποφάσεις), ένα ενιαίο αίτημα ανά υπηρεσία.
3. Τι αποφασίστηκε για λογαριασμό σας — τεχνικές επιλογές που αξίζει να ξέρετε συν κάθε SAFE DEFAULT, το καθένα αναστρέψιμο με μία γραμμή.
4. Τι μένει ανοιχτό — γνωστά όρια, μέρη που αναβλήθηκαν, τι πρέπει να ξέρει το επόμενο ticket.

Ο αυτοέλεγχος πριν την αναφορά. Ο agent πρώτα ρωτά τον εαυτό του: μπορεί ο reviewer να με κλείσει και να αφήσει την εκτέλεση να συνεχίσει; Ό,τι έγινε ή καταγράφηκε (μια αλλαγή που έκανε και κατέγραψε, ένα bug που διόρθωσε, μια σημείωση για το επόμενο ticket) δεν είναι ανοιχτό θέμα — πηγαίνει στα μέρη 3/4. Ό,τι χρειάζεται εσάς είναι yes. Μια τεχνική αμφιβολία λύνεται πριν την αναφορά: μια άλλη προσέγγιση, μετά ΕΝΑΣ helper. Έτσι το NEEDS THE USER: no έρχεται πάντα με OPEN ISSUES AND DOUBTS: none. Μια αναφορά που λέει no αλλά καταγράφει θέματα, ή δεν έχει καθόλου τις δύο γραμμές, επιστρέφεται από τον auto-reviewer μία φορά (ένα μήνυμα 📨 SYSTEM (auto-reviewer) που λέει τι είναι λάθος) αντί να κρατηθεί για εσάς· μια δεύτερη αντιφατική αναφορά σας περιμένει.

Στο μέρος 3 ξοδεύετε την προσοχή σας: κάθε ασφαλής προεπιλογή είναι μια επιχειρησιακή υπόθεση που μπορείτε να ανατρέψετε με μία πρόταση. Το μέρος 2 σας λέει τι πρέπει να ζητήσετε από τον πελάτη. Μια αναφορά χωρίς απόδειξη στο μέρος 1 είναι αναφορά για την οποία πρέπει να είστε καχύποπτοι — ελέγξτε τη λίστα αποδοχής του SPEC FILE και το screenshot. Μια αναφορά που τελειώνει με μια ευγενική ερώτηση («Να κάνω επίσης…;») σημαίνει ότι ο agent σας χρειάζεται — οι οδηγοί το απαγορεύουν ακριβώς επειδή σταματά το πλάνο.

5.9 Επαλήθευση και ο βρόχος διόρθωσης — ένας verifier έχει την ευθύνη του επεισοδίου

1. Ticket [VERIFY] (διαφορετική οικογένεια providers, senior + balanced, basic για τετριμμένο/απλό γονικό, pro μόνο για πολύ κρίσιμο γονικό· εφαρμόστε τους ζωντανούς περιορισμούς providers και ledger — parent_sequence/parent_ticket_id = ο builder· το guides/verify-fix.md προφορτώνεται): διατρέχει τη λίστα αποδοχής του γονικού, τρέχει τη συνταγή και τη δική του ομάδα tests του ticket και τις ομάδες που επηρεάζονται, γράφει τα δικά του αρνητικά tests, γράφει μόνο το δικό του SPEC FILE και αρχεία tests. Τα ευρήματα αριθμούνται με βήματα, αναμενόμενο και παρατηρούμενο· οι προτιμήσεις στυλ δεν είναι ευρήματα. Ένα ομαδικό verify ονομάζει πολλά γονικά (ένα ticket μετά το τελευταίο από αυτά).
2. Κανένα εύρημα → VERIFY: PASS · cycle 1 στο SPEC FILE του γονικού, αναφορά NEEDS THE USER: no. Ο reviewer το κλείνει· το πλάνο συνεχίζει.
3. Ευρήματα → μόνο αφού ολοκληρωθεί κάθε έλεγχος κάθε γονικού, ο verifier δημιουργεί όλες τις διορθώσεις του κύκλου μαζί: [FIX] <parent title> (#<parent id>, cycle 1, k/m) — <the finding>, μία ανά εύρημα ή ανά μικρή ομάδα ευρημάτων στο ίδιο σημείο (το πολύ 5 ανά κύκλο — ένας fixer παίρνει ένα συγκεκριμένο πρόβλημα, που χωρά στο μικρό του context) — ο provider του αρχικού builder, και ρόλος και think mode σύμφωνα με την κλίμακα διορθώσεων (κύκλος 1 = του ίδιου του builder, κύκλος 2 = ένα βήμα think πάνω, κύκλος 3 = senior + pro), στο δικό του sequence_order του verifier. Πολλές διορθώσεις τρέχουν ΠΑΡΑΛΛΗΛΑ όταν τα αρχεία τους είναι χωριστά (η καθεμία με μια γραμμή OWNS: που επιβάλλει η πλατφόρμα) και ΣΕΙΡΙΑΚΑ (depends_on την προηγούμενη διόρθωση) όταν ένα αρχείο είναι κοινό. Γράφει VERIFY: FAIL · cycle 1 · … · fix #<id> στο SPEC FILE του γονικού, και σταθμεύει μία φορά: ⏸ WAITING-FOR-TICKET #<fix id> (⏸ WAITING-FOR-ALL-TICKETS #<id>, #<id> για πολλές). Ένας σταθμευμένος verifier κρατά τη σειρά του ανολοκλήρωτη, οπότε η διόρθωση τρέχει αμέσως και όλα τα επόμενα περιμένουν.
4. Η διόρθωση διορθώνει μόνο τα καταγεγραμμένα ευρήματα, το καθένα με ένα επαναλήψιμο test που αποτυγχάνει πριν και περνά μετά· ένα εύρημα με το οποίο διαφωνεί σημειώνεται DISPUTED με απόδειξη. Όταν τελειώσει γράφει FIX: done · cycle 1 στο SPEC FILE του γονικού και απαντά στον verifier (codehero_update_ticket(ticket_id=<verifier>, reply="FIX done — cycle 1 — fix #<id>")) — η απάντηση ξυπνά τον verifier. Δεν δημιουργεί ποτέ verify ticket.
5. Ο verifier ξυπνά (κύκλος 2), ξαναελέγχει μόνο τα ευρήματα (συν τα στοιχεία αποδοχής που αγγίζουν και τις ομάδες γονικών που επηρεάζονται και τους σχετικούς αρνητικούς ελέγχους του verifier), και είτε γράφει VERIFY: PASS · cycle 2 και αναφέρει, είτε ανοίγει τη διόρθωση του κύκλου 2 και σταθμεύει ξανά.
6. Circuit breaker: το ίδιο μέρος απέτυχε τρεις κύκλους, το ίδιο στοιχείο αποδοχής απέτυχε δύο φορές στη σειρά, ή builder και verifier διαφώνησαν δύο φορές σε ένα εύρημα → ο verifier σταματά, γράφει CIRCUIT BREAKER στο αρχείο, αναφέρει NEEDS THE USER: yes με τις δύο απόψεις και τις διεξόδους — (a) ένας ακόμη κύκλος διόρθωσης, ένα βήμα πιο πάνω· (b) μια απευθείας επισκευή: ανεβάζετε τον verifier σε master + ultra, επισκευάζει μόνο εκείνα τα ευρήματα, και ένα [PEER] της άλλης οικογένειας providers τα ξαναελέγχει και δίνει το PASS· (c) αποδοχή ή αλλαγή του κριτηρίου (επιχειρησιακή απόφαση, επίσης γραμμή στο change ledger)· (d) στάθμευση του μέρους για μεταγενέστερη φάση — και μένει ανοιχτό μέχρι να αποφασίσετε (η απόφασή σας καταγράφεται ως USER DECISION και ξεκινά νέα μέτρηση).

Το αρχείο των κύκλων βρίσκεται στον δίσκο, στο SPEC FILE του γονικού (γραμμές VERIFY: / FIX:, μόνο προσθήκες· αποφασίζει η τελευταία γραμμή VERIFY:), επειδή κάθε διόρθωση είναι νέος agent με άδεια μνήμη και ο ίδιος ο verifier μπορεί να επανεκκινηθεί. Όταν δείτε ένα [FIX] να εμφανίζεται στη σειρά του verifier, μην κάνετε τίποτα· είναι ο βρόχος που δουλεύει. Όταν δείτε το ίδιο μέρος να αποτυγχάνει για τρίτη φορά, περιμένετε τον breaker και προετοιμαστείτε να επιλέξετε μία από τις διεξόδους του (βήμα 6).

5.10 Helper tickets και το walkie-talkie

Οποιοδήποτε ticket μπορεί να ανοίξει ένα [HELPER] — σε άλλον provider όταν υπάρχει ενεργός, αλλιώς στον δικό του provider, κανονικά senior + balanced, ποτέ πιο αδύναμο από αυτό που το ανοίγει· master μόνο με ρητό αίτημα του χρήστη — όταν έχει πραγματικά κολλήσει (βήμα 8 του debugging), όταν δύο προσεγγίσεις απέτυχαν και δεν μπορεί να επιλέξει, όταν μία σχεδιαστική απόφαση μπλοκάρει ό,τι ακολουθεί, ή όταν ερωτήσεις πρόκειται να πάνε στον χρήστη (το φίλτρο «πρώτα AI, μετά άνθρωπος»). Κανόνες (guides/helper.md): οι helpers δεν γράφουν ποτέ αρχεία και δεν δημιουργούν ποτέ tickets· το ticket που ανοίγει έναν helper τον κλείνει (status="closed") πριν από το δικό του TASK COMPLETED· ένας helper ανά ticket, που φέρει όλες τις αμφιβολίες του μαζί. Μετά από τρεις ανταλλαγές, ο agent που έχει την ευθύνη αποφασίζει ένα τεχνικό ζήτημα από τις διαθέσιμες αποδείξεις και καταγράφει το σκεπτικό. Μια επιχειρησιακή απόφαση, αλλαγή scope, δεδομένο που λείπει ή ανεπίλυτο απαιτούμενο αποτέλεσμα πηγαίνει στον χρήστη με τις δύο απόψεις και τη συγκεκριμένη απόφαση που χρειάζεται· μην κατασκευάζετε συμφωνία ή επιχειρησιακή προεπιλογή. Ένας helper μπορεί να βρει μια απάντηση που υπάρχει στο υλικό και να κρίνει ένα τεχνικό αντιστάθμισμα· δεν μπορεί ποτέ να επινοήσει επιχειρησιακό γεγονός.

Το πρωτόκολλο μηνυμάτων είναι απλό και την παράδοση την κάνει η πλατφόρμα. Το codehero_update_ticket(ticket_id=<other numeric id>, reply="...") στέλνει· η πλατφόρμα το υπογράφει (📨 FROM TICKET #<id> (<number> · <title>)), οπότε ένα μήνυμα χωρίς υπογραφή είναι από άνθρωπο. Ένα ticket που δουλεύει το λαμβάνει στο επόμενο βήμα του — μέσω του δικού του ελέγχου κατά την εκτέλεση, μέσα στο αποτέλεσμα του επόμενου εργαλείου MCP, ή (στις λειτουργίες Claude CLI) μέσω ενός hook PostToolUse — μέσα σε δευτερόλεπτα. Σταθμεύστε για ένα ticket με ⏸ WAITING-FOR-TICKET #<id> (<number> · <title>) — its reply will wake me. Για ένα σύνολο του οποίου χρειάζεστε όλα τα αποτελέσματα, χρησιμοποιήστε ⏸ WAITING-FOR-ALL-TICKETS #<id>, #<id> (<number> · <title>; ...) — all replies will wake me· ξυπνά μία φορά αφού απαντήσουν ή τελειώσουν όλα. Μη χρησιμοποιείτε τον δείκτη ενός ticket με λίστα IDs χωρισμένων με κόμμα. Ένα ticket που τελειώνει τη σειρά του με αδιάβαστο μήνυμα ξανανοίγει αμέσως από τον daemon. Ένα σταθμευμένο ticket του οποίου τα αναμενόμενα tickets τελείωσαν χωρίς να απαντήσουν ξυπνά από έναν watchdog με μια σημείωση 📨 SYSTEM, ώστε τίποτα να μην περιμένει για πάντα.

Η πλατφόρμα παρακολουθεί την αναμονή, και προς τις δύο κατευθύνσεις (καταγράφει ποιο ticket άνοιξε ποιο: created_by_ticket_id). Ένα ticket που άνοιξε ένα άλλο — ένας peer, ένας helper, ένας worker, η διόρθωση ενός verifier — και τελειώνει τη σειρά του χωρίς να απαντήσει στον δημιουργό του αναφέρεται στον δημιουργό με την τελική του αναφορά και το «if it has not given you an answer, ask it again — something went wrong», και ο δημιουργός ξυπνά. Όταν ένα ticket τελειώνει τη σειρά του και κάποιο ticket είναι σταθμευμένο περιμένοντάς το, αυτός που περιμένει παίρνει μια σημείωση 📨 SYSTEM (waiting-check) και ξυπνά για να ρωτήσει ξανά (το πολύ δύο φορές, μετά αφήνεται σε εσάς) — δύο tickets που περιμένουν το ένα το άλλο δεν μπορούν πια να παγώσουν μια εκτέλεση. Τα κλειστά tickets δεν ξυπνούν ποτέ. Ένας lead workers σταθμεύει με ⏸ WAITING-FOR-ALL-TICKETS και ξυπνά μία φορά, όταν έχει έρθει όλο το σύνολο.

Μηνύματα μόνο για ενημέρωση. Το codehero_update_ticket(ticket_id=…, reply=…, wake=false) παραδίδει μια ειδοποίηση με σήμανση ℹ️ FOR YOUR INFORMATION που δεν ξυπνά κανέναν: ένα ticket σε αναμονή τη διαβάζει όταν ξυπνήσει για δικό του λόγο. Ένα ticket που κατέγραψε αλλαγή απαίτησης ενημερώνει με αυτόν τον τρόπο τα ανολοκλήρωτα tickets (guides/update.md).

Στη λίστα tickets αυτό φαίνεται έτσι: ένα build ticket σε εξέλιξη, ένα ticket [HELPER] ή [PEER] σε άλλον provider με τον ίδιο αριθμό σειράς, τα δύο ανταλλάσσουν αριθμημένα ευρήματα, μετά ο helper κλείνεται από αυτόν που τον άνοιξε πριν εκείνος πει TASK COMPLETED. Ένας ανοιχτός helper που έμεινε πίσω αφού τελείωσε αυτός που τον άνοιξε είναι λάθος του τελευταίου — και κρατά κάθε μεταγενέστερη σειρά.

5.11 Το replan ticket

Το ticket [REPLAN] κλείνει κάθε φάση — και τη μοναδική φάση ενός μικρού project, όπου είναι ο τελικός έλεγχος. Δεν χτίζει τίποτα: διαβάζει το baseline συν το change ledger (.specs/000-changes.md), κοιτάζει το πραγματικό project (κώδικα, SHOW CREATE TABLE, τις σελίδες στο preview URL, το ΠΛΗΡΕΣ bash .tests/run.sh — η μία πλήρης εκτέλεση της φάσης, που ξεκινά πρώτη και διαβάζεται παράλληλα) αντί για τις αναφορές, και γράφει έναν πίνακα σύγκρισης και προς τις δύο κατευθύνσεις — κάθε απαίτηση που οφείλεται → πού βρίσκεται και τι την αποδεικνύει· καθετί που χτίστηκε → ποια απαίτηση το ζήτησε — με aligned / missing / wrong / not asked for / unknown / not yet due. Μετά μία από τέσσερις αποφάσεις: ALIGNED → σχεδιάζει την επόμενη φάση (ίδιοι κανόνες: contracts, σειρά αξίας, dry run, περίπου δέκα γύροι review, και ΠΑΝΤΑ ο έλεγχος από peer)· REPAIR NEEDED → μια φάση tickets επισκευής (+ τα [VERIFY] τους) που τελειώνει με νέο [REPLAN] — κάθε επισκευή διαστασιολογείται όπως κάθε build (μία εστιασμένη εκτέλεση, ≤ ~12 στοιχεία αποδοχής, ≤ ~15 αρχεία· μια επισκευή που πρέπει να κοιτάξει όλο το project, όπως μια απογραφή κάθε πίνακα ή log, χωρίζεται ανά περιοχή) — καμία νέα λειτουργία μέχρι ένα replan να πει aligned, και circuit breaker μετά από τρεις γύρους επισκευής στην ίδια απαίτηση· NEEDS THE USER → μία δέσμη ερωτήσεων και διακοπή· BLOCKED → λέει τι λείπει. Το baseline, το ledger και οι τρέχουσες αποφάσεις παραμένουν η πηγή αλήθειας. Χρησιμοποιήστε τον οριοθετημένο διασταυρωτικό έλεγχο του planning guide για μη καταγεγραμμένες αλλαγές του ιδιοκτήτη, με περιορισμένη αναζήτηση tickets και στοχευμένα μηνύματα· μην ξαναδιαβάζετε ολόκληρες συνομιλίες και μην αλλάζετε σιωπηλά το baseline. Δεν ζητά ξανά έγκριση — το εγκεκριμένο πλάνο το περιλάμβανε — εκτός αν πρέπει να αλλάξει το scope. Το τελευταίο replan ενός project είναι ο τελικός έλεγχος.

5.12 Τα χειριστήρια του operator

5.13 Ανάγνωση μιας εκτέλεσης σαν operator — λίστα ελέγχου

Για κάθε ολοκληρωμένο ticket:

• &#9744; Η αναφορά ξεκινά με NEEDS THE USER: και OPEN ISSUES AND DOUBTS:, έχει τα τέσσερα μέρη, και το μέρος 1 παραπέμπει σε αποδείξεις που μπορείτε να ανοίξετε (ένα screenshot, ένα URL, ένα όνομα test).
• &#9744; Η λίστα ACCEPTANCE του SPEC FILE έχει διατρεχθεί· κάθε στοιχείο είναι pass ή BLOCKED με αιτία· τίποτα δεν διαγράφηκε για να φαίνεται πράσινο.
• &#9744; Το STATUS στο .specs/ δείχνει την τελική θέση· το NEXT: είναι κενό ή δείχνει στο επόμενο ticket.
• &#9744; Το knowledge graph απέκτησε τις αποφάσεις και τα αδιέξοδα που αναφέρει το ticket.
• &#9744; Κανένα helper ή peer ticket δεν έμεινε ανοιχτό.
• &#9744; Υπάρχει το snapshot της τελικής κατάστασης (backup_log).
• &#9744; Αν το ticket ρώτησε κάτι: η ερώτηση είναι επιχειρησιακός κανόνας, όχι τεχνική επιλογή· ήρθε σε μία δέσμη· την φιλτράρισε πρώτα ένας helper.
• &#9744; Αν ένα VERIFY ticket παρήγαγε ευρήματα: υπάρχει ένα [FIX] ανά εύρημα (ή μικρή ομάδα στο ίδιο σημείο, το πολύ 5) στη σειρά του verifier (τα παράλληλα με γραμμές OWNS:, τα σειριακά με depends_on), ο verifier είναι σταθμευμένος σε αυτά, και καμία μεταγενέστερη σειρά δεν ξεκίνησε.

Ασκήσεις — Ενότητα 5

1. Δημιουργήστε με το χέρι ένα πρόχειρο project (ένα project και ένα build ticket: μια σελίδα PHP με φόρμα που αποθηκεύει μια γραμμή). Τρέξτε το σε λειτουργία supervised και εγκρίνετε κάθε κλήση. Καταγράψτε κάθε εργαλείο που χρησιμοποίησε ο agent και ποιο επίπεδο του context του είπε να χρησιμοποιήσει εκείνο το εργαλείο.
2. Τρέξτε το ίδιο ticket σε λειτουργία autonomous. Συγκρίνετε το transcript: βρείτε τη δημιουργία του SPEC FILE, τις κλήσεις snapshot, τη συνταγή επαλήθευσης, την αποθήκευση γνώσης, την αναφορά 4 μερών. Σημειώστε κάθε βήμα που παρέλειψε και παραπέμψτε στην ενότητα του global που παραβίασε.
3. Δημιουργήστε σκόπιμα ένα ticket του οποίου η περιγραφή παραλείπει έναν επιχειρησιακό κανόνα (π.χ. «εφάρμοσε την έκπτωση» χωρίς να λέει πώς). Παρατηρήστε τη διακοπή-και-ερώτηση. Απαντήστε στη μορφή «1A, 2B» και παρακολουθήστε το ξανάνοιγμα. Μετά ελέγξτε ότι η απάντηση κατέληξε στο SPEC FILE και στη knowledge base.
4. Δημιουργήστε με το χέρι ένα ticket [VERIFY] για το ticket της άσκησης 1 (διαφορετική οικογένεια providers, senior, balanced, parent_ticket_id = εκείνο το ticket). Διαβάστε τα ευρήματά του. Αν παρήγαγε ένα [FIX], ελέγξτε τον provider του, τη σειρά του και τον δείκτη στάθμευσης του verifier απέναντι στην §5.9· παρακολουθήστε τον verifier να ξυπνά και να ξαναελέγχει.
5. Ενεργοποιήστε σκόπιμα τον ανιχνευτή βρόχων (ένα ticket στο οποίο λέτε «συνέχισε να τρέχεις το test που αποτυγχάνει μέχρι να περάσει» σε ένα test που δεν μπορεί να περάσει). Βρείτε το μήνυμα του hook στο transcript και τη στιγμή που ο agent άλλαξε προσέγγιση ή σταμάτησε.
6. Εξηγήστε σε έναν συνάδελφο, χρησιμοποιώντας το διάγραμμα κύκλου ζωής, γιατί ένα σειριακό πλάνο με ένα ticket σε awaiting_input δείχνει όλα τα μεταγενέστερα tickets ως «σε αναμονή», και γιατί αυτό είναι σωστό.

---

ΜΕΡΟΣ VI — ΠΡΟΣΑΡΜΟΓΗ ΤΟΥ «ΕΓΚΕΦΑΛΟΥ»

Ενότητα 6 — Χτίζοντας τη δική σας λογική με το global context και το project context

6.1 Τα επίπεδα, πού βρίσκονται και ποιος τα διαβάζει

Τέσσερα γεγονότα καθορίζουν πώς διαδίδεται μια αλλαγή:

1. Από την 4.66.2, ο εγκατεστημένος πυρήνας και οι ενότητες stack που επιλέγονται από το project_stack φορτώνονται σε κάθε εκτέλεση· δεν αντιγράφονται ποτέ μέσα σε ένα project. Τα global_context, project_context και context περιέχουν μόνο τις προσθήκες που ζήτησε ρητά ο χρήστης, με τα δικά του λόγια. Μη βάζετε σε αυτά τα πεδία τον πυρήνα, μια ενότητα stack, έναν οδηγό, ένα template, μια αυτόματα παραγόμενη ανάλυση project ή την προδιαγραφή. Η προδιαγραφή ανήκει στο planning ticket.
2. Τα πεδία φτάνουν στους agents μόνο όταν το additional_context_enabled είναι ενεργό. Τα νέα projects ξεκινούν ενεργά· τα projects που υπήρχαν κατά την αναβάθμιση 4.66.2 ξεκινούν ανενεργά. Τα overrides εφαρμόζονται πάνω από τις προεπιλογές της πλατφόρμας, με σειρά global < app < notes.
3. Πριν καθαρίσετε παλιό περιεχόμενο ή ενεργοποιήσετε overrides, διαβάστε τα υπάρχοντα πεδία, ξεχωρίστε τα εγκατεστημένα αντίγραφα από τις προσθήκες του πελάτη, δείξτε ακριβώς τι θα αλλάξει και πάρτε την επιβεβαίωση του χρήστη. Το clear_context_fields=true καθαρίζει το global και το app context σύμφωνα με το schema του εργαλείου· μην υποθέτετε ότι διατηρεί κείμενο του πελάτη ή ότι καθαρίζει τα notes. Διατηρήστε τις επιβεβαιωμένες προσθήκες του πελάτη. Δεν υπάρχει ενέργεια ανανέωσης του global context. Το codehero_get_context_defaults είναι μόνο για ανάγνωση· μην αντιγράφετε ποτέ το αποτέλεσμά του μέσα σε ένα project.
4. Τα placeholders επιλύονται μόνο στο global context. Γράψτε εκεί {PROJECTS_PORT} και {PROJECT_FOLDER}· ποτέ ένα κυριολεκτικό port. Τα αρχεία ανά γλώσσα δεν φέρουν placeholders (χρησιμοποιούν το {web_path} μόνο ως όνομα μέσα στο κείμενο).

Deploy μιας αλλαγής context σε server:

# global: source → installed defaults AND the daemon/assistant copy
sudo cp /home/claude/codehero/config/global-context.md /opt/codehero/config/global-context.md
sudo cp /home/claude/codehero/config/global-context.md /etc/codehero/global-context.md
# per-language: source → installed defaults
sudo cp /home/claude/codehero/config/contexts/php.md /opt/codehero/config/contexts/php.md
# guides: source → installed (read by codehero_get_guide)
sudo cp /home/claude/codehero/config/guides/*.md /opt/codehero/config/guides/
# assistant templates
sudo cp /home/claude/codehero/config/assistant-planner.md /etc/codehero/assistant-planner.md

Τα εγκατεστημένα αντίγραφα αντικαθίστανται από τα setup.sh / upgrade.sh· κρατήστε τις προσαρμογές σας στο δέντρο πηγαίου κώδικα (ή σε ένα fork) και εφαρμόστε τες ξανά μετά τις αναβαθμίσεις. Το upgrade.sh αντικαθιστά επίσης το /etc/codehero/heroagent.conf (το προηγούμενο κρατιέται ως heroagent.conf.bak.<date>). Όσο τρέχει μια αναβάθμιση (5.0.2), από μετά το backup της μέχρι να ολοκληρωθούν τα βήματα βάσης δεδομένων, ρυθμίσεων και υπηρεσιών, κανένα ticket δεν ξεκινά· τα tickets που τρέχουν συνεχίζουν, και όσα περιμένουν ξεκινούν αμέσως μετά.

6.2 Ποιο επίπεδο για ποιον κανόνα

Ένας κανόνας στο λάθος επίπεδο είναι το πιο συνηθισμένο λάθος προσαρμογής: ο τύπος ΦΠΑ ενός πελάτη στο global context διαρρέει στο project κάθε άλλου πελάτη· ένας κανόνας μεθόδου σε ένα ticket ξεχνιέται από το επόμενο ticket.

6.3 Πώς είναι γραμμένο το global context — και γιατί

Το τρέχον global context (v6.2: ένας πυρήνας συν δεκαπέντε οδηγοί κατ' απαίτηση, φορτωμένοι ανά ενότητα· ο παρεχόμενος πυρήνας v6.2 είναι 47.535 bytes UTF-8· τα μεγέθη των οδηγών διαφέρουν ανά εγκατεστημένη έκδοση και πρέπει να μετριούνται, όχι να αντιγράφονται σε μόνιμο κανόνα) είναι γραμμένο σε απλά αγγλικά ώστε κάθε μοντέλο, μεγάλο ή μικρό, να μπορεί να το ακολουθήσει. Από την 4.66.0 ο πυρήνας περιέχει επίσης τους κανόνες πλοήγησης για τεράστια projects (βρείτε πριν διαβάσετε — ο χάρτης κώδικα, η περιορισμένη αναζήτηση, οι επικεφαλίδες ενός εγγράφου, οι μεγάλες έξοδοι σε ένα log στο .tmp/) και τον κανόνα ότι κάθε αλλαγή που ζητά ο χρήστης ενημερώνει κάθε αρχείο που περιγράφει την παλιά συμπεριφορά· οι διαδικασίες βρίσκονται σε ΕΝΟΤΗΤΕΣ οδηγών που φορτώνει η πλατφόρμα ή ανοίγει ο agent. Οι συμβάσεις του δεν είναι θέμα στυλ· είναι αυτό που κάνει τα αδύναμα μοντέλα να συμμορφώνονται. Κρατήστε τες όταν προσθέτετε ή αλλάζετε κανόνες:

Το μέγεθος μετρά. Ο παρεχόμενος πυρήνας v6.2 είναι 47.535 bytes UTF-8 και στέλνεται με κάθε ticket· έναν οδηγό τον πληρώνουν μόνο τα tickets που τον χρειάζονται· τα μεγέθη των οδηγών διαφέρουν ανά εγκατεστημένη έκδοση και πρέπει να μετριούνται, όχι να αντιγράφονται σε μόνιμο κανόνα. Κάθε παράγραφος που προσθέτετε στον πυρήνα πληρώνεται σε κάθε ticket κάθε project: ένας κανόνας για μια αναγνωρίσιμη κατάσταση ανήκει σε έναν οδηγό, με μια γραμμή αφορμής στην Ενότητα 2 του πυρήνα — ποτέ στον πυρήνα. Τρέξτε python3 tests/context/check_global_context.py μετά από κάθε επεξεργασία (παραπομπές, πίνακας αφορμών, tokens, πίνακες).

6.4 Ο κανόνας για την αλλαγή κανόνων

Κάθε αυστηρός κανόνας στο global context κατονομάζει το περιστατικό που αποτρέπει (H2: οι διεργασίες σκοτώνονται όταν τελειώνει η σειρά· H3: γραμμές που εισήχθησαν χειροκίνητα για να περάσει ένα test· H6: δύο tickets που επεξεργάζονται το ίδιο αρχείο). Ένας κανόνας που προστίθεται «για καλό και για κακό» μήπως ένα μοντέλο κάνει κάτι έχει κόστος σε κάθε ticket και καμία απόδειξη ότι βοηθά· και ένας αμυντικός κανόνας για μια υποθετική αποτυχία συχνά κάνει το μοντέλο υπερβολικά επιφυλακτικό στην πραγματική δουλειά. Όταν ένας εκπαιδευόμενος προτείνει μια αλλαγή context, ζητήστε το transcript που δείχνει την αποτυχία. Χωρίς transcript → καμία αλλαγή.

Το ίδιο ισχύει για την αφαίρεση ενός κανόνα: βρείτε το περιστατικό που αποτρέπει (το ιστορικό του git και το CHANGELOG καταγράφουν τα περισσότερα) πριν τον διαγράψετε.

6.5 Προσαρμογή στην πράξη 1 — μια σύμβαση της εταιρείας στο global context

Παρατηρημένη αποτυχία: τρία projects παραδόθηκαν χωρίς κανένα ημερολόγιο αλλαγών· το τμήμα πληροφορικής του πελάτη δεν μπορούσε να πει τι είχε αλλάξει ένα ticket.

Αλλαγή: στην CORE Ενότητα 11, προσθέστε το CHANGELOG.md στη λίστα, και στο βήμα ενημέρωσης αρχείων της Ενότητας 5 προσθέστε μία γραμμή: "Append one line to CHANGELOG.md: ticket number · date · what changed." Δύο προτάσεις, στις δύο ενότητες όπου το μοντέλο ήδη αναζητά υποχρεώσεις τεκμηρίωσης. Όχι νέος αυστηρός κανόνας (ένα changelog που λείπει δεν είναι αποτυχία ασφάλειας), όχι νέα ενότητα.

Έλεγχος (§6.10): ένα δοκιμαστικό project στο πιο αδύναμο ενεργό μοντέλο· μετά από ένα ticket, το CHANGELOG.md υπάρχει με μία γραμμή.

6.6 Προσαρμογή στην πράξη 2 — μια παραλλαγή stack (Laravel αντί για απλή PHP)

Το PHP context προδιαγράφει απλή PHP με PDO και ένα κανονικό includes/config.php. Η ομάδα ενός πελάτη συντηρεί projects σε Laravel και θέλει το CodeHero να ακολουθεί τις συμβάσεις της.

Δύο τρόποι, και πρέπει να ξέρετε και τους δύο:

• Ανά project (χωρίς αλλαγή στην πλατφόρμα). Δημιουργήστε το project με το stack του (project_stack=["php", "mysql"]) και βάλτε ΜΟΝΟ τη διαφορά στο project_context, με τα λόγια της ομάδας — π.χ. «Αυτό είναι project Laravel: εντολές artisan, routes/web.php, Eloquent + migrations, layouts Blade, php artisan test· αγνόησε το bootstrap και το μοτίβο σελίδας της απλής PHP». Ο agent το διαβάζει ως USER PROJECT OVERRIDE, πάνω από την ενότητα PHP. Μην επικολλάτε ποτέ εκεί αντίγραφο της ενότητας PHP ή του πυρήνα: από την 4.66.2 αυτά φορτώνονται από τα εγκατεστημένα αρχεία σε κάθε εκτέλεση, και ένα αντίγραφο απορρίπτεται.
• Ένα νέο αρχείο stack για κάθε μελλοντικό project. Προσθέστε το config/contexts/laravel.md. Σημειώστε ότι η αντιστοίχιση stack-σε-αρχείο είναι κώδικας (context_map στο scripts/mcp_server.py και ο αντίστοιχος χάρτης στο web/app.py), οπότε μια νέα τιμή tech_stack χρειάζεται μια μικρή αλλαγή από developer και στους δύο χάρτες συν την επιλογή στο UI· ένα stack χωρίς αντιστοίχιση πέφτει σιωπηλά πίσω στο php. Μέχρι να επεκταθεί ο χάρτης, χρησιμοποιήστε τη διαδρομή ανά project.

Όποια διαδρομή κι αν επιλέξετε, το αρχείο πρέπει να κρατά τη γραμμή κεφαλίδας που δηλώνει ότι φορτώνεται μετά το global context και παραπέμπει σε αυτό, και δεν πρέπει να επαναλαμβάνει κανόνες του global (σχετικά paths, ασφάλεια, βιβλιοθήκες) — παραπέμψτε αντί αυτού στο «Global Section 11».

6.7 Προσαρμογή στην πράξη 3 — το project context ενός εισαγόμενου παλιού project

Για ένα εισαγόμενο project, τρέξτε το codehero_analyze_project και καταγράψτε την επαληθευμένη δομή και τις συμβάσεις στον χάρτη του και στη γνώση του project. Βάλτε την αλλαγή που ζήτησε ο χρήστης και την αποδεκτή υπάρχουσα συμπεριφορά στην παράδοση σχεδιασμού· διατηρήστε το baseline σύμφωνα με την περίπτωση D. Γράψτε ένα μόνιμο override μόνο αν ο χρήστης ζητήσει ρητά να διατηρηθεί εκείνος ο κανόνας, με τα δικά του λόγια, αφού του δείξετε την προτεινόμενη αλλαγή πεδίου. Μην προβιβάζετε την αρχιτεκτονική ή τη συνταγή tests που συμπέρανε ένας agent σε overrides του χρήστη.

6.8 Προσαρμογή στην πράξη 4 — ένα project μόνο API

Ένα HTTP API ακολουθεί το GUIDE: verification.md και το GUIDE: testing.md: πραγματικά requests μέσω της προκαθορισμένης διαδρομής preview, επανανάγνωση αποθήκευσης/απόκρισης, αρνήσεις εξουσιοδότησης και validation με θετικούς ελέγχους, οριοθετημένα logs και οι ομάδες tests που επηρεάζονται. Ένα API χωρίς UI δεν χρειάζεται νέα ροή Browser. Τα native/μη-HTTP προϊόντα ακολουθούν το GUIDE: native.md για τους εφαρμόσιμους ελέγχους.

Βάλτε τα endpoints του project, τα αναμενόμενα αποτελέσματα και τις πραγματικές εντολές tests στην αποδοχή του ticket και στα έγκυρα contracts. Μη γράφετε μια εναλλακτική διαδικασία επαλήθευσης της πλατφόρμας στα πεδία context του χρήστη. Ένα εργαλείο επαλήθευσης που λείπει ή διαφέρει το χειρίζονται οι εγκατεστημένοι οδηγοί, όχι ένα επινοημένο api context ή μια Ενότητα 15 του πυρήνα.

6.9 Προσαρμογή στην πράξη 5 — επιχειρησιακοί κανόνες του πελάτη

Λάθος: προσθήκη του «Ο ΦΠΑ είναι 24% και εφαρμόζεται στο καθαρό ποσό, με στρογγυλοποίηση μισού προς τα πάνω» στο global context.

Σωστό: κρατήστε τον επιχειρησιακό κανόνα και το παράδειγμά του στην αμετάβλητη προδιαγραφή που φέρει το PLAN, μετά στο baseline/change ledger του και στο έγκυρο contract. Το planning ticket καταγράφει την απόφαση στη γνώση του project και δίνει σε κάθε ticket που επηρεάζεται τις αναφορές απαίτησης/αποδοχής του. Η περιγραφή του project περιέχει μόνο μια σύντομη εντολή.

6.10 Έλεγχος μιας αλλαγής context — το πρωτόκολλο

1. Diff και μέγεθος. diff απέναντι στην προηγούμενη έκδοση· ελέγξτε την αλλαγή μεγέθους του αρχείου. Μια αλλαγή που προσθέτει πάνω από μερικές εκατοντάδες bytes χρειάζεται αιτιολόγηση.
2. Κρατήστε την κεφαλίδα έκδοσης. Η πρώτη γραμμή του global context ονομάζει την έκδοσή του· αυξήστε την και προσθέστε μία γραμμή στη σημείωση από κάτω που λέει τι άλλαξε και ποια αποτυχία διορθώνει.
3. Κάντε deploy στα εγκατεστημένα paths (§6.1). Δεν χρειάζεται επανεκκίνηση.
4. Ελέγξτε και ένα νέο και ένα υπάρχον πρόχειρο project. Επιβεβαιώστε ότι η επόμενη εκτέλεση φορτώνει το νέο εγκατεστημένο αρχείο οδηγιών· τα πεδία context του χρήστη μένουν κενά ή κρατούν μόνο τις προσθήκες του πελάτη. Ελέγξτε το επιλυμένο preview URL στο πραγματικό συντεθειμένο prompt χωρίς να εκθέσετε διαπιστευτήρια.
5. Τρέξτε ένα δοκιμαστικό ticket δύο φορές: μία στον ισχυρότερο provider σας, μία στο πιο αδύναμο μοντέλο που πράγματι χρησιμοποιείτε για junior_developer. Ο κανόνας πρέπει να αντέχει στο αδύναμο· αν τον ακολουθεί μόνο το ισχυρό μοντέλο, ξαναγράψτε τον (πιο σύντομα, IF/THEN, ένα παράδειγμα με πραγματικές τιμές).
6. Εξετάστε μόνο τη συγκεκριμένη ενότητα οδηγιών που χρειάζεται για να επιβεβαιωθεί η φόρτωση. Χρησιμοποιήστε μια λογοκριμένη ή οριοθετημένη, χωρίς secrets, όψη του συντεθειμένου prompt· μην εκτυπώνετε ή επισυνάπτετε ποτέ τα διαπιστευτήρια βάσης δεδομένων/υπηρεσιών του, τις τιμές προστατευμένων paths ή ολόκληρο το prompt. Καταγράψτε την πηγή/έκδοση των οδηγιών και την παρουσία τους μία φορά, χωρίς περιεχόμενο διαπιστευτηρίων.
7. Διαβάστε το transcript για τη συμπεριφορά, όχι για τα λόγια: έκανε ο agent το πράγμα (το αρχείο υπάρχει, ο έλεγχος έτρεξε), ή είπε ότι θα το κάνει;
8. Οι αλλαγές στις εγκατεστημένες οδηγίες φτάνουν στα υπάρχοντα projects στην επόμενη εκτέλεσή τους. Μην ανανεώνετε ή επικολλάτε κείμενο πυρήνα/stack στα πεδία του project. Ελέγξτε το additional_context_enabled χωριστά με ένα μικρό, ρητά εγκεκριμένο override χρήστη, διατηρώντας το προϋπάρχον κείμενο του πελάτη.
9. Καταγράψτε την αλλαγή στο CHANGELOG του αποθετηρίου με το περιστατικό που διορθώνει.

6.11 Αντι-μοτίβα (το καθένα έχει εμφανιστεί σε πραγματική εκτέλεση)

6.12 Προσαρμογή του planner και των assistants

Η ίδια πειθαρχία ισχύει για το config/assistant-planner.md και τα άλλα templates του assistant: διαβάζονται ανά συνεδρία, συνενώνονται με το global context (εκτός από το help), και φέρουν αυστηρούς κανόνες στην κορυφή. Τυπικές θεμιτές προσαρμογές: ένα προεπιλεγμένο strategy για την εταιρεία (eco), ένας εσωτερικός κανόνας για τις οικογένειες providers στην επαλήθευση, επιπλέον στήλες στο preview, ένα διαφορετικό προεπιλεγμένο execution mode για μια εκπαιδευτική εγκατάσταση. Αθέμιτες: αφαίρεση της πύλης preview-και-επιβεβαίωσης, επιτρεπόμενοι ανενεργοί providers, παραλληλισμός ως προεπιλογή. Καθεμία από αυτές αναιρεί μια αρχή της Ενότητας 1.

Ασκήσεις — Ενότητα 6

1. Πάρτε την προσαρμογή της §6.5 και εφαρμόστε την στην εκπαιδευτική σας εγκατάσταση ακολουθώντας το πρωτόκολλο της §6.10 από την αρχή ως το τέλος. Επισυνάψτε: το diff, ένα λογοκριμένο απόσπασμα μόνο της ενότητας οδηγιών που άλλαξε, χωρίς διαπιστευτήρια, τη γραμμή του transcript όπου ο agent γράφει το CHANGELOG.md.
2. Γράψτε ένα context ανά project για ένα project Node/Express που πρέπει να χρησιμοποιεί ένα υπάρχον πακέτο middleware της εταιρείας για auth. Δείξτε σε ποιες ενότητες του global παραπέμπετε αντί να τις επαναλαμβάνετε.
3. Εξετάστε τα απενεργοποιημένα πεδία override ενός παλιού project. Εντοπίστε τα παλιά εγκατεστημένα αντίγραφα και τις γνήσιες προσθήκες του πελάτη. Προτείνετε και επιβεβαιώστε έναν καθαρισμό που διατηρεί εκείνες τις προσθήκες· επιδείξτε τη φόρτωση από τα εγκατεστημένα αρχεία και τον διακόπτη override χωρίς να αντιγράψετε προεπιλογές στα πεδία.
4. Ένας εκπαιδευόμενος προτείνει να προστεθεί «Πάντα να ελέγχεις διπλά τη δουλειά σου πριν τελειώσεις» στο global context. Υποστηρίξτε υπέρ ή κατά χρησιμοποιώντας τις §6.3 και §6.4, μετά προτείνετε μια εκδοχή που θα άλλαζε πράγματι τη συμπεριφορά (υπόδειξη: υπάρχει ήδη — βρείτε την).
5. Γράψτε έναν κανόνα για το global context που θα είχε αποτρέψει αυτή την παρατηρημένη αποτυχία: «Ο agent ανέφερε ένα email ως σταλμένο· τα διαπιστευτήρια SMTP ήταν placeholders· τίποτα δεν στάλθηκε.» Μετά βρείτε την πρόταση στον πυρήνα v6.2 που ήδη το καλύπτει και συγκρίνετε τη διατύπωση.

---

ΜΕΡΟΣ VII — ΦΤΑΝΟΝΤΑΣ ΣΕ ΛΕΙΤΟΥΡΓΙΚΟ ΑΠΟΤΕΛΕΣΜΑ

Ενότητα 7 — Πειθαρχία παράδοσης: από το πρώτο ticket σε επαληθευμένο, τεκμηριωμένο προϊόν

7.1 Τι σημαίνει «λειτουργικό αποτέλεσμα» στο ADF

Όχι «ο κώδικας γράφτηκε». Λειτουργικό αποτέλεσμα σημαίνει: το συμφωνημένο scope τρέχει στο preview URL (και αργότερα στο domain παραγωγής), κάθε κριτήριο αποδοχής έχει συνδεδεμένη απόδειξη, κάθε επιχειρησιακός κανόνας επιβεβαιώθηκε από τον πελάτη και είναι αποθηκευμένος εκεί όπου τον βρίσκει το επόμενο ticket, τα μπλοκαρισμένα μέρη καταγράφονται με τα ακριβή τους αιτήματα, και η τεκμηρίωση που συμφώνησε ο πελάτης υπάρχει στη γλώσσα του. Το framework σας φέρνει εκεί ταξινομώντας τη δουλειά ώστε τα πιο επικίνδυνα άγνωστα να επιλύονται πρώτα και οι αποδείξεις να συσσωρεύονται στην πορεία.

7.2 Η εναρκτήρια σειρά: setup → πύλη πρόσβασης → βασικό κομμάτι

Μόνο αφού επαληθευτεί το βασικό κομμάτι ξεκινούν οι δευτερεύουσες λειτουργίες (λίστες επιθυμιών, branding, σκούρο θέμα, επιπλέον αναφορές). Αν ένας πελάτης πιέζει για το λογότυπο πρώτα, δείξτε του αυτόν τον πίνακα: το λογότυπο δεν μπορεί να αποτύχει· η ολοκλήρωση αγοράς μπορεί.

7.3 Ορόσημα και η συχνότητα replan

Ο Spec Builder προτείνει αποτελέσματα ταξινομημένα κατά αξία και προαιρετικές υποψήφιες κάρτες. Το planning ticket διαστασιολογεί και προγραμματίζει τις πραγματικές φάσεις στην εγκατάσταση· οι αριθμοί είναι εκτιμήσεις, όχι ποσοστώσεις. Κάθε σχεδιασμένη φάση τελειώνει σε REPLAN. Η επαλήθευση ακολουθεί τον κίνδυνο, το μέγεθος, τον εγκεκριμένο ρυθμό και την επιλεξιμότητα providers· το πακέτο δεν προδιαγράφει ξεχωριστό ticket επαλήθευσης μετά από κάθε contract ή λειτουργία.

7.4 Contracts πριν από τον κώδικα

Γράψτε κάθε κοινό contract μία φορά στο έγκυρο αριθμημένο αρχείο του πριν δημιουργήσετε τους καταναλωτές του. Τα tickets-καταναλωτές ονομάζουν ακριβείς ενότητες/εκδόσεις και τα δικά τους SPEC FILEs· τα σύντομα αποσπάσματα σημειώνονται ως αναφορές, όχι ως ανεξάρτητοι ορισμοί. Το planning ticket δημιουργεί το ίδιο τα αρχεία contracts και τις αποφάσεις γνώσης. Τα ξεχωριστά tickets contract/επαναεπικύρωσης δεν είναι αυτόματη αλυσίδα. Ενημερώστε το τρέχον contract και κάθε αρχείο που επηρεάζεται σύμφωνα με τη διαδικασία αλλαγών, διατηρώντας το ιστορικό και ακυρώνοντας τις αποδείξεις που επηρεάζονται.

7.5 Αποδείξεις και το manifest αποδοχής

Κάθε κριτήριο αποδοχής στο πακέτο τελειώνει με απόδειξη: έκδοση απαίτησης, revision κώδικα, ID test, περιβάλλον. Η στήλη Evidence του μητρώου απαιτήσεων συμπληρώνεται μόνο από πραγματική έξοδο tests — ποτέ από το κείμενο ενός ticket. Σε όρους CodeHero: η αναφορά του VERIFY ticket, τα screenshots (codehero_screenshot), τα αποτελέσματα PageAssert και η έξοδος του test runner είναι οι αποδείξεις· η λίστα ACCEPTANCE του SPEC FILE είναι το σημείο όπου ο agent καταγράφει pass / fail / BLOCKED ανά στοιχείο.

Δύο κανόνες εντιμότητας στους οποίους πρέπει να επιμένει ο εκπαιδευτής: ένα στοιχείο BLOCKED είναι ορατό και δεν μετριέται ποτέ ως pass· το καθαρό αποτέλεσμα ενός παθητικού ελέγχου ασφαλείας καταγράφει τι ελέγχθηκε, όχι ότι «δεν υπάρχουν προβλήματα».

7.6 Ημέρα 0, σημεία επαφής, και πώς κρατάτε τον πελάτη έξω από τον βρόχο κατασκευής

Πριν την εκτέλεση: συγκεντρώστε το πακέτο ημέρας 0 (Ενότητα 2 §2.12). Κατά την εκτέλεση: δεδομένα με υπεύθυνο και οι πύλες έγκρισης/επαφής που ορίζονται στην §2.12. Όλα τα υπόλοιπα είναι δική σας δουλειά ως operator: απαντήστε σε τεχνικές ερωτήσεις που θα έπρεπε να είχε αποφασίσει ο agent (πείτε του να αποφασίσει), κυνηγήστε τον πελάτη μόνο για γνήσιες επιχειρησιακές αποφάσεις, και κρατήστε το Decision Log της προδιαγραφής συγχρονισμένο με κάθε απάντηση που μεταφέρετε. Μια εκτέλεση που σταματά καθημερινά με επιχειρησιακές ερωτήσεις έχει ελλιπή προδιαγραφή· μια εκτέλεση που σταματά καθημερινά με τεχνικές ερωτήσεις έχει πρόβλημα context (Ενότητα 6)· μια εκτέλεση που δεν σταματά ποτέ αλλά παραδίδει λάθος συμπεριφορά έχει πρόβλημα επαλήθευσης (Ενότητα 5 §5.9).

7.7 Circuit breakers — όταν το framework σταματά μόνο του

Οι breakers δεν είναι αποτυχίες του framework· είναι το framework που αρνείται να καίει χρήματα σε ένα πρόβλημα που χρειάζεται άνθρωπο.

7.8 Παραδοτέα τεκμηρίωσης

Πάντα, στη γλώσσα του πελάτη: ένα εγχειρίδιο χρήσης ανά ρόλο, ένας οδηγός διαχειριστή, ένας οδηγός λειτουργίας/hosting (εγκατάσταση, αναβάθμιση, backup, επαναφορά, παρακολούθηση), τεκμηρίωση API όταν υπάρχει API, και ένα έγγραφο Decisions που καταγράφει καθετί που αποφασίστηκε για λογαριασμό του πελάτη. Μέσα στο project ο agent συντηρεί επίσης τα technologies.md, map.md και τα αρχεία .specs/. Το ticket που ολοκληρώνει τη ροή ενός ρόλου γράφει τη βοήθεια εκείνου του ρόλου. Το τελευταίο build συντάσσει προσχέδιο του υλικού παράδοσης· ο τελικός έλεγχος ολοκληρώνει τα docs/acceptance.md και docs/handover.md με πραγματικές αποδείξεις. Μη δημιουργείτε αυτόνομα tickets τεκμηρίωσης μόνο για να γεμίσει ένα template.

7.9 Από το preview στην παραγωγή

Το preview URL είναι εκεί όπου δουλεύουν οι agents. Η έναρξη λειτουργίας είναι εργασία του operator, που γίνεται με τα εργαλεία της πλατφόρμας και τεκμηριώνεται στο User Guide:

7.10 Η καθημερινή λίστα ελέγχου του operator

• &#9744; Tickets σε awaiting_input: αιτία; question → απάντηση σε μία δέσμη· permission → allow/deny· completed (strict) → review της αναφοράς και κλείσιμο· stopped → διόρθωση και retry.
• &#9744; Tickets σε failed μετά τα retries ή σε stuck: διαβάστε τα τελευταία μηνύματα, διορθώστε την αιτία (κείμενο ticket, περιβάλλον, διαπιστευτήρια), κάντε retry.
• &#9744; Helpers και peers που άφησαν ανοιχτούς ολοκληρωμένα tickets: κλείστε και σημειώστε.
• &#9744; Μετρήστε τους ολοκληρωμένους αποτυχημένους κύκλους επισκευής στο αρχείο μόνο-προσθηκών του verifier, όχι τον αριθμό των FIX tickets. Το αρχικό εύρημα δεν είναι αποτυχημένη επισκευή. Σταματήστε όταν το ίδιο μέρος αποτύχει σε τρεις ολοκληρωμένους κύκλους επισκευής, το ίδιο στοιχείο αποδοχής αποτύχει σε δύο επισκευές στη σειρά, ή υπάρξουν δύο αμφισβητήσεις σε ένα εύρημα, όπως ορίζει το GUIDE: verify-fix.md.
• &#9744; Το replan ticket της φάσης: διαβάστε το πλάνο του πριν τρέξει αν θέλετε αλλαγές scope.
• &#9744; Ανάπτυξη της knowledge base: αποθηκεύονται αποφάσεις και αδιέξοδα (ένα επίπεδο graph μετά από πολλά tickets = πρόβλημα context).
• &#9744; Υπάρχουν snapshots για κάθε ολοκληρωμένο ticket· το πιο πρόσφατο επαναφέρεται καθαρά (ελέγξτε το μία φορά ανά ορόσημο).
• &#9744; Στοιχεία ημέρας 0 που λείπουν ακόμη: κυνηγήστε τον πελάτη· τα στοιχεία BLOCKED εξαρτώνται από αυτά.

7.11 Ένας κατάλογος πραγματικών μοτίβων αποτυχίας και τι σημαίνουν

Κάθε στοιχείο παρακάτω συνέβη σε πραγματική εκτέλεση. Μάθετε να τα αναγνωρίζετε από το transcript.

Ασκήσεις — Ενότητα 7

1. Πάρτε το πλάνο RepairFlow της Ενότητας 4. Για καθένα από τα πρώτα πέντε tickets γράψτε την απόδειξη που παράγει (μια πρόταση που ονομάζει το αντικείμενο που θα ανοίγατε για να το ελέγξετε).
2. Γράψτε το πακέτο ημέρας 0 για το RepairFlow στη γλώσσα του πελάτη, και τη λίστα επαφών τεσσάρων λόγων όπως θα τη στέλνατε στον ιδιοκτήτη.
3. Προσομοιώστε έναν breaker: ένα VERIFY ticket αναφέρει «η προθεσμία υπολογίζεται ως +15 ημέρες», το fix ticket απαντά «η προδιαγραφή λέει 14 εργάσιμες ημέρες» (DISPUTED), ο verifier ξαναελέγχει και διαφωνεί ξανά. Γράψτε το μήνυμα που στέλνετε στον σταθμευμένο verifier, και τη γραμμή που προσθέτετε στο Decision Log.
4. Αναθέστε την τεκμηρίωση κάθε ρόλου του RepairFlow στο ticket που παραδίδει τη ροή του, και προσδιορίστε ποιος συντάσσει και ποιος επαληθεύει την τελική παράδοση.
5. Διαλέξτε τρεις γραμμές του καταλόγου αποτυχιών και βρείτε την ακριβή πρόταση στο global context (ή στον planner) που υπάρχει εξαιτίας τους.

---

ΜΕΡΟΣ VIII — ΤΕΛΙΚΗ ΕΡΓΑΣΙΑ

Ενότητα 8 — Η τελική εργασία και η αξιολόγηση

8.1 Η ανάθεση

Σε ζευγάρια (ο ένας παίζει τον πελάτη, ο άλλος τον developer· μετά αλλάζετε), παραδώστε ένα μικρό εσωτερικό εργαλείο από άκρη σε άκρη μέσα σε μία εργάσιμη ημέρα:

1. Πάρτε συνέντευξη από τον πελάτη με τον Spec Builder (Ενότητα 2). Παραδώστε ένα πακέτο Ready for active-scope construction — με δηλωμένα, όχι υποτιθέμενα, τα IDs ενεργών απαιτήσεων και τις αποδείξεις ετοιμότητας — με το πολύ ένα μη κρίσιμο στοιχείο Assumed. Το εργαλείο πρέπει να έχει: δύο ρόλους, μία οντότητα με τουλάχιστον τρεις καταστάσεις και ιστορικό, έναν επιχειρησιακό κανόνα με αριθμό (μια προθεσμία, ένα όριο ή έναν τύπο), μία ειδοποίηση, μία εξαγωγή ή εκτύπωση.
2. Αιτιολογήστε το stack (Ενότητα 3): την απόφαση μίας γραμμής, το block περιβάλλοντος, και την απάντηση στο «γιατί όχι container;» (ή «γιατί container;»).
3. Σχεδιάστε το σε IMPORT MODE (Ενότητα 4). Πριν επιβεβαιώσετε, παράγετε ένα γραπτό review του preview: τρεις αλλαγές που κάνατε και γιατί.
4. Τρέξτε τη φάση 1 (Ενότητα 5) σε relaxed autonomous λειτουργία. Απαντήστε σε κάθε ερώτηση που προκύπτει στη μορφή «1A, 2B». Κρατήστε το Decision Log συγχρονισμένο.
5. Προσαρμόστε ένα πράγμα (Ενότητα 6) που η εκτέλεση έδειξε ότι χρειαζόταν — με το transcript που αποδεικνύει την ανάγκη, το diff, τον έλεγχο της §6.10.
6. Παραδώστε (Ενότητα 7): το βασικό κομμάτι επαληθευμένο στο preview URL από ένα VERIFY ticket σε διαφορετική οικογένεια providers· την παράδοση 4 μερών για τον πελάτη· η τεκμηρίωση για τις ροές που παραδόθηκαν υπάρχει, και τα acceptance/handover καταγράφουν τις πραγματικές αποδείξεις και τα κενά με υπεύθυνο· τα στοιχεία ημέρας 0 καταγεγραμμένα.

8.2 Η κλίμακα αξιολόγησης

8.3 Κουίζ αυτοαξιολόγησης

Απαντήστε χωρίς να κοιτάξετε· μετά ελέγξτε με τις ενότητες αναφοράς.

1. Ονομάστε τα δύο είδη αγνώστων που συναντά ο agent, και ποιος αποφασίζει για το καθένα. (Global §4)
2. Τι κάνει ο agent όταν μια CRITICAL ερώτηση δεν έχει απάντηση και η εκτέλεση είναι αυτόνομη; (Global §4.1, guides/asking.md)
3. Ποιες καταστάσεις ticket ικανοποιούν μια εξάρτηση; Το awaiting_input; Το timeout; (Ενότητα 5 §5.1)
4. Δώστε τις τρεις ρυθμίσεις που πρέπει να έχει κάθε VERIFY ticket, πού πηγαίνει το fix ticket του, και ένα πράγμα που δεν πρέπει να κάνει ποτέ. (guides/verify-fix.md)
5. Ποια είναι η προεπιλογή εγκατάστασης του MAX_PARALLEL_TICKETS_PER_PROJECT, και τι σημαίνει αυτό για ένα πλάνο όπου δύο tickets μοιράζονται sequence_order; (Ενότητα 4 §4.6)
6. Γιατί ο Spec Builder δεν κατονομάζει ποτέ provider ή μοντέλο; (Planning Guide §1.2, §7.5)
7. Ποια τέσσερα πράγματα δηλώνει χωριστά το block codehero_environment, και ποιο από αυτά μόνο του καθορίζει το container_required; (Ενότητα 3 §3.6)
8. Πού ανήκει ο κανόνας ΦΠΑ ενός πελάτη, και πού δεν ανήκει; (Ενότητα 6 §6.2)
9. Ποια είναι τα τέσσερα μέρη της αναφοράς παράδοσης, και ποιο μέρος περιέχει τις ασφαλείς προεπιλογές; (Global §5 βήμα 10)
10. Το τελευταίο μήνυμα ενός ticket είναι ⏸ WAITING-FOR-TICKET #418. Το ticket 418 τρέχει ακόμη. Τι κάνει ο auto-reviewer; (Ενότητα 5 §5.1)
11. Ονομάστε τρία «επικίνδυνα αρχεία» που ελέγχει ονομαστικά η ανάλυση ιδιοκτησίας. (guides/planning.md §2)
12. Ποιο αρχείο ξαναδιαβάζει πρώτο ο agent όταν νιώθει χαμένος μετά από compaction; (Global §6)
13. Ποια είναι η διαφορά ανάμεσα σε ένα SAFE DEFAULT και σε έναν μαντεμένο επιχειρησιακό κανόνα; (Global §4.1, guides/asking.md)
14. Γιατί οι οδηγίες των tickets πρέπει να παραλείπουν ονόματα containers/εσωτερικές IP ενώ διατηρούν αληθή στοιχεία deploy και execution context; Εξηγήστε την εξαίρεση του εγκεκριμένου SETUP για κενά υπηρεσιών.
15. Ένας εκπαιδευόμενος θέλει να προσθέσει έναν κανόνα «να είσαι πάντα προσεκτικός με τα χρήματα». Τι ζητάτε πρώτα; (Ενότητα 6 §6.4)
16. Ένα build ticket στη σειρά 3 αφήνεται σε awaiting_input από τον reviewer. Μπορεί να ξεκινήσει ένα ticket στη σειρά 4; Ένα εξαναγκασμένο ticket στη σειρά 9; (Ενότητα 4 §4.6)
17. Ποιες δύο γραμμές ανοίγουν κάθε αναφορά agent, και τι κάνει ο reviewer με την καθεμία; (Ενότητα 5 §5.8)

8.4 Λίστα ελέγχου πιστοποίησης

Ένας developer είναι έτοιμος να τρέχει projects πελατών χωρίς επίβλεψη όταν μπορεί να:

• &#9744; διεξάγει μια συνέντευξη Spec Builder και να εξετάζει το πακέτο της με τη λίστα ελέγχου της Ενότητας 2·
• &#9744; δηλώνει την απόφαση stack και την αιτιολόγησή της για οποιαδήποτε από τις οκτώ μικρές περιπτώσεις χωρίς σημειώσεις·
• &#9744; διαβάζει ένα preview του planner και να βρίσκει τα τρία πιο συνηθισμένα ελαττώματα (λάθος provider για το verify, οπτική δουλειά σε provider μόνο κειμένου, εξάρτηση που λείπει)·
• &#9744; απαντά σωστά σε μια δέσμη ερωτήσεων ενός agent (μόνο επιχειρησιακά, μία δέσμη, ενημερωμένο Decision Log)·
• &#9744; αναγνωρίζει τα δώδεκα μοτίβα αποτυχίας της Ενότητας 7 από ένα transcript·
• &#9744; αλλάζει έναν κανόνα context ακολουθώντας το πρωτόκολλο της §6.10 και να δείχνει το transcript που αποδεικνύει ότι λειτούργησε·
• &#9744; εξηγεί τις δώδεκα αρχές σε έναν πελάτη με απλή γλώσσα.

---

ΠΑΡΑΡΤΗΜΑΤΑ

Παράρτημα A — Κάρτες γρήγορης αναφοράς

A.1 Πεδία ticket

Οι γραμμές is_forced και created_by_ticket_id περιγράφουν αποθηκευμένα πεδία· δεν είναι παράμετροι του create_ticket.

A.2 Καταστάσεις ticket

open (επιλέξιμο) · in_progress (ο agent τρέχει) · awaiting_input (σταθμευμένο: completed / question / error / permission / stopped / deps_ready) · done (αυτό σημαίνει και το «close» — δεν υπάρχει κατάσταση closed) · failed (εξαντλήθηκαν τα retries) · stuck (watchdog) · timeout · skipped (μετρά ως ολοκληρωμένο). Στον κανονικό χρονοπρογραμματισμό, μια μεγαλύτερη σειρά ξεκινά μόνο όταν κάθε μικρότερη είναι done ή skipped.

A.3 Ρόλοι και think modes ανά τύπο ticket

Πρώτα το μέγεθος: μια μικρή αλλαγή σε κάτι υπάρχον χρησιμοποιεί ένα συνηθισμένο build ticket, συν επαλήθευση όταν το απαιτούν οι περιορισμοί providers. Μια απλή νέα κατασκευή (περίπου τρεις οθόνες ή λιγότερες, ένας τύπος χρήστη, χωρίς login, χρήματα, ενοποιήσεις ή προσωπικά δεδομένα) χρησιμοποιεί ένα build και ένα VERIFY άλλης οικογένειας. Μεγαλύτερη δουλειά χρησιμοποιεί την εγκεκριμένη προδιαγραφή και ένα PLAN ticket· μόνο εκείνο το ticket σχεδιάζει και δημιουργεί τις φάσεις εργασίας.

Ένα μικρό πλάνο έχει έως περίπου πέντε tickets εργασίας, δύο ομάδες review, ένα τελικό VERIFY και REPLAN, και έναν peer για εφαρμόσιμη επικίνδυνη δουλειά. Ένα πραγματικό πλάνο χρησιμοποιεί έως δέκα ομάδες review, έναν peer και φάσεις περίπου δέκα tickets που τελειώνουν σε REPLAN. Ο γρήγορος ρυθμός (fast) χρησιμοποιεί λιγότερες ομάδες· το ultra-fast είναι ένα demo που ζητήθηκε ρητά, με δηλωμένες παραλείψεις. Οι αριθμοί είναι όρια ή εκτιμήσεις, όχι ποσοστώσεις. Οι περιορισμοί σταδιακής ενεργοποίησης providers ισχύουν σε κάθε ρυθμό.

Τα PLAN, REPLAN, PEER, VERIFY και HELPER κανονικά χρησιμοποιούν senior_developer + balanced· ένας peer/helper δεν είναι ποτέ πιο αδύναμος από αυτόν που τον άνοιξε. Το pro είναι για πολύ κρίσιμο πυρήνα ή για την τεκμηριωμένη κλιμάκωση μετά από αποτυχία. Η δουλειά γίνεται από junior_developer ανάλογα με τη δυσκολία: τετριμμένη off, πολύ απλή fast, απλή basic, μέτρια balanced· η δύσκολη δουλειά είναι senior + balanced. Το master_developer μόνο με ρητό αίτημα. Το ultra δεν είναι ποτέ προεπιλογή project ούτε αυτόματη ρύθμιση για chain tickets.

Ο κύκλος FIX 1 χρησιμοποιεί τον ρόλο και το think mode του builder· ο κύκλος 2 ανεβαίνει ένα βήμα think· ο κύκλος 3 χρησιμοποιεί senior + pro, ποτέ κάτω από τον builder. Τα επεισόδια ασφάλειας χρησιμοποιούν senior + pro· τα επεισόδια απόδοσης χρησιμοποιούν senior + balanced, με την προκαθορισμένη εξαίρεση για κρίσιμο SLA. Η δουλειά release είναι senior_developer + balanced (GUIDE: release.md). Το planning ticket εφαρμόζει τους τρέχοντες οδηγούς, τις εξαιρέσεις ρυθμού, την επιλεξιμότητα και τις επιλογές του χρήστη.

A.4 Τα εργαλεία του agent

Ενσωματωμένα: Read Write Edit MultiEdit Glob Grep Bash ProcessManager HttpRequest Browser PageAssert LogTail WebFetch GetCached. Πλατφόρμας (MCP): codehero_knowledge_search/store/list/delete · codehero_search_tickets · codehero_codebase_query (με ενεργό χάρτη) · codehero_semantic_search (με ενεργή σημασιολογική αναζήτηση) · codehero_git_operations · codehero_screenshot · codehero_extract_context · codehero_get_guide · codehero_get_ticket update_ticket (απάντηση, κατάσταση) create_ticket list_tickets bulk_create_tickets get_project_progress start_ticket · codehero_get_project get_providers_info · codehero_container_operations · codehero_codebase_status.

A.5 Το global context, ανά ενότητα

Πυρήνας: 0 Read this first (γλωσσάρι, έξι κανόνες) · 1 Κανόνας γλώσσας · 2 Οδηγοί: ο πίνακας αφορμών · 3 Αυστηροί κανόνες H1–H10 · 4 Αποφασίζω μόνος ή ρωτώ (4.1 ερωτήσεις, ασφαλείς προεπιλογές, blocked) · 5 Ο βρόχος εργασίας (+ ο ελαφρύς βρόχος για μικρή αλλαγή) · 6 Το SPEC FILE · 7 Knowledge base · 8 Όταν κάτι αποτυγχάνει · 9 Επαλήθευση (9.1 τίποτα εσωτερικό διαθέσιμο για λήψη, 9.2 επαναλήψιμα tests) · 10 Git backup · 11 Κανόνες κώδικα · 12 Μηνύματα μεταξύ tickets · 13 Περιβάλλον & paths · 14 Τελική λίστα ελέγχου. Οδηγοί: planning · verify-fix · asking · update · helper · debugging · frontend · database · build · testing · verification · coding · native · services · release.

A.6 Walkie-talkie

Αποστολή: codehero_update_ticket(ticket_id=<other numeric id>, reply="...") — η πλατφόρμα το υπογράφει 📨 FROM TICKET #<id>. Λήψη κατά την εκτέλεση: 📨 INCOMING MESSAGE στο επόμενο βήμα (δικός του έλεγχος, αποτέλεσμα MCP, ή hook του CLI). Στάθμευση για ένα ticket με ⏸ WAITING-FOR-TICKET #<id> (<number> · <title>) — its reply will wake me + TASK COMPLETED. Για ένα σύνολο του οποίου χρειάζεστε όλα τα αποτελέσματα, χρησιμοποιήστε ⏸ WAITING-FOR-ALL-TICKETS #<id>, #<id> (<number> · <title>; ...) — all replies will wake me· ξυπνά μία φορά αφού απαντήσουν ή τελειώσουν όλα. Μη χρησιμοποιείτε τον δείκτη ενός ticket με λίστα IDs χωρισμένων με κόμμα. Ένα αναμενόμενο ticket που τελειώνει χωρίς να απαντήσει προκαλεί αφύπνιση 📨 SYSTEM. Τελείωσε με αδιάβαστο μήνυμα → ξανανοίγει αμέσως. Κλείστε έναν helper που ανοίξατε: codehero_update_ticket(ticket_id=<helper>, status="closed"). Ένα ticket που ανοίξατε και τελειώνει χωρίς να απαντήσει → η αναφορά του + «ρώτα το ξανά». Σταθμευμένο για ένα ticket που τώρα περιμένει κι αυτό → 📨 SYSTEM (waiting-check). Μόνο ενημέρωση: reply=…, wake=false (δεν ξυπνά κανέναν).

Παράρτημα B — Χάρτης αρχείων

Παράρτημα C — Λίστα ανάγνωσης (με σειρά)

1. config/global-context.md — διαβάστε το δύο φορές· είναι το framework. Μετά τα config/guides/planning.md, verify-fix.md, helper.md, asking.md — οι καταστάσεις.
2. docs/CODEHERO_PLANNING_GUIDE.md — πρώτα τα Μέρη 1, 2, 3 και 7· τα Μέρη 4–6 ως αναφορά.
3. config/assistant-planner.md — σύντομο· διαβάστε το πριν από την πρώτη σας εισαγωγή.
4. config/contexts/php.md — το context γλώσσας αναφοράς· μετά το context του δικού σας stack.
5. Κεφάλαια του User Guide 8 (Execution Modes), 9 (Sequencing), 11 (Lifecycle), 13–16 (providers, ρόλοι, think mode, vision), 31 (Containers), 32 (Production).
6. docs/SMARTCONTEXT.md — πώς λειτουργεί το compaction και γιατί υπάρχει το SPEC FILE.
7. CHANGELOG.md — το ιστορικό περιστατικών πίσω από τους κανόνες.
8. Η παρουσίαση The Domain Expert's Software Factory — η ίδια μέθοδος ειπωμένη στην πλευρά του πελάτη· χρήσιμη πριν από την άσκηση συνέντευξης της Ενότητας 2.

---

Εκπαίδευση developers CodeHero v1.10 — ελεγμένη απέναντι στο CodeHero PRO 5.0.2, Global Context v6.2 και Spec Builder 1.27, 2026-10-15. Τα τρέχοντα αρχεία του framework υπερισχύουν αυτού του προγράμματος.

Ερωτήσεις που μας κάνουν

Όλα τα άρθρα ↗

Είμαι δεμένος με μία εταιρεία AI;

Όχι. Το CodeHero δουλεύει με πολλές εταιρείες AI μαζί και με μοντέλα στο δικό σας hardware. Αλλάζετε εταιρεία ή μοντέλο όποτε θέλετε — το έργο, οι κανόνες και το ιστορικό του μένουν. Διαβάστε το άρθρο ↗

Φτάνουν οι κωδικοί και τα κλειδιά μου στην εταιρεία AI;

Όχι. Οι κωδικοί και τα κλειδιά που αποθηκεύετε ως μυστικά χρησιμοποιούνται από την εφαρμογή σας, αλλά οι τιμές τους δεν στέλνονται ποτέ στην υπηρεσία AI. Διαβάστε το άρθρο ↗

Γιατί δουλεύουν πολλά AI στην ίδια δουλειά;

Γιατί ένα AI δεν πιάνει τα δικά του τυφλά σημεία. Στο CodeHero ένα μοντέλο φτιάχνει και ένα μοντέλο άλλης εταιρείας ελέγχει· τα προβλήματα επιστρέφουν για διόρθωση και ελέγχονται ξανά. Διαβάστε το άρθρο ↗

Πώς συγκρίνεται το CodeHero με άλλα εργαλεία κώδικα με AI;

Είναι διαφορετικό είδος. Τα εργαλεία κώδικα βοηθούν όποιον γράφει κώδικα. Το CodeHero κάνει όλη τη δουλειά — ρωτά, σχεδιάζει, φτιάχνει, ελέγχει, φιλοξενεί, συντηρεί — για όποιον ξέρει την επιχείρηση. Διαβάστε το άρθρο ↗

Αν το CodeHero γράφει τον κώδικα, ποιος είναι ο δικός μου ρόλος;

Γίνεστε ο σύμβουλος: αποφασίζετε τους κανόνες της επιχείρησης, εγκρίνετε το σχέδιο και παραλαμβάνετε το αποτέλεσμα. Το CodeHero είναι ο developer που ρωτά, φτιάχνει, ελέγχει και συντηρεί. Διαβάστε το άρθρο ↗

Πώς κρατά το AI τη μνήμη του σε μεγάλες δουλειές;

Με το memory folding: όταν το AI τελειώσει με ένα μεγάλο αποτέλεσμα, κρατά μια σύντομη σημείωση με τα σημαντικά και βάζει το υπόλοιπο στην άκρη — μπορεί να το ανοίξει ξανά όποτε θέλει. Έτσι δουλεύει πολύ περισσότερο χωρίς να χάνει το νήμα. Διαβάστε το άρθρο ↗

Πώς αποφεύγει το AI να ξεχνά ή να μπερδεύεται σε ένα μεγάλο έργο;

Το εργοστάσιο του δίνει δομή: έξυπνα tickets με μία καθαρή δουλειά το καθένα, ένα βιβλίο αλλαγών με κάθε απόφαση, έναν χάρτη του κώδικα και αναζήτηση με βάση το νόημα. Το AI διαβάζει όσα χρειάζεται αντί να μαντεύει — και αυτό γλιτώνει και πολύ κόστος. Διαβάστε το άρθρο ↗

Γιατί το λέτε εργοστάσιο και όχι εργαλείο;

Γιατί τρέχει μόνο του όλη τη γραμμή παραγωγής — σχεδιασμό, κατασκευή, ανεξάρτητο έλεγχο, διόρθωση, παράδοση και συντήρηση — με σταθμούς, κανόνες και αρχεία, όπως ένα εργοστάσιο. Ένα εργαλείο περιμένει έναν άνθρωπο να το χρησιμοποιήσει. Διαβάστε το άρθρο ↗

Πώς μπορεί αυτό να αλλάξει τον κόσμο των εφαρμογών;

Όταν ο άνθρωπος που ξέρει τη δουλειά μπορεί να αποκτήσει λογισμικό φτιαγμένο, ελεγμένο, φιλοξενούμενο και συντηρημένο χωρίς ομάδα ανάπτυξης, το λογισμικό μπορεί να φτιάχνεται για κάθε επιχείρηση και κάθε ανάγκη — όχι μόνο για όσους αντέχουν μια ομάδα. Διαβάστε το άρθρο ↗

Τι σημαίνει το CodeHero για τους developers;

Λιγότερη επαναλαμβανόμενη δουλειά και λιγότερα ξενύχτια. Το εργοστάσιο αναλαμβάνει τη ρουτίνα — κατασκευή, έλεγχο, διορθώσεις· οι developers αποφασίζουν την αρχιτεκτονική, ελέγχουν ό,τι μετράει και λύνουν τα δύσκολα. Διαβάστε το άρθρο ↗

Γιατί το CodeHero φιλοξενεί και τις εφαρμογές;

Γιατί η κατασκευή και η λειτουργία πάνε μαζί. Η εφαρμογή τρέχει εκεί όπου φτιάχτηκε, με το domain, την ασφαλή σύνδεση, τα backups και την επαναφορά της — και κάθε επόμενη αλλαγή επιστρέφει στο ίδιο εργοστάσιο. Κανένα ξεχωριστό πάνελ φιλοξενίας να μάθετε. Διαβάστε το άρθρο ↗

Τι τεχνολογία χρησιμοποιούν οι εφαρμογές;

Πάντα ανοιχτές, ευρέως διαδεδομένες τεχνολογίες — πρώτα PHP και MySQL, και άλλες όπως Node, Python ή .NET όταν το χρειάζεται η δουλειά. Η εφαρμογή σας δεν κλειδώνεται ποτέ σε κλειστή πλατφόρμα. Διαβάστε το άρθρο ↗

Γιατί συνδρομές AI και όχι πληρωμή ανά χρήση;

Γιατί στις δικές μας μετρήσεις, σε έντονη καθημερινή δουλειά, μια συνδρομή κόστισε έως και περίπου 40 φορές λιγότερο από την πληρωμή ανά χρήση για την ίδια δουλειά. Το CodeHero τρέχει τα εργαλεία AI με συνδρομή (Claude Code, Codex, Grok Build) ως εργάτες στο εργοστάσιο. Διαβάστε το άρθρο ↗

Τι γίνεται η γνώση για το έργο μου;

Χτίζεται και κρατιέται μέσα στη δική σας εγκατάσταση: αποφάσεις, κανόνες, αλλαγές και οι αιτίες τους, δίπλα στον κώδικα. Ένας νέος άνθρωπος ή ένα νέο AI συνεχίζει από εκεί — η γνώση δεν φεύγει μαζί τους. Διαβάστε το άρθρο ↗

Μπορούν μικρά τοπικά μοντέλα AI να κάνουν πραγματική δουλειά;

Μέσα στο εργοστάσιο, ναι — περισσότερη από όση μόνα τους. Μικρά, καθαρά tickets, ένας έλεγχος ολοκλήρωσης, βοήθεια στα εργαλεία και ένα ισχυρότερο μοντέλο που ελέγχει το αποτέλεσμα επιτρέπουν σε μικρά μοντέλα στο δικό σας hardware να κάνουν μεγάλο μέρος της κατασκευής. Διαβάστε το άρθρο ↗