Anvay - Ground 0

[CyberLord09]

Ground Zero Check — CSH / OCS Intelligence Infrastructure

Sprint focus: Move from onboarding into project development by proving that I can independently use the development environment, document technical work, collaborate through GitHub, and turn an ambiguous infrastructure problem into a concrete engineering plan.

Project direction: Build and research a distributed OCS AI infrastructure system that combines a cloud control plane, a Mac Mini worker/session pool, and two 8× GTX 1070 GPU rigs connected through a private NetBird network.

---

Executive Summary

My biggest change during Ground Zero was moving from thinking about the project as “set up some computers that can run AI” to understanding it as a distributed systems and AI orchestration problem.

At the beginning, the individual technologies were easier for me to understand than the way they all needed to work together. I already had experience with GitHub, Linux, servers, networking, and software development, but the difficult part was defining a clean architecture for a system with many different responsibilities: public access, authentication, session state, temporary state, Mac Mini workers, GPU workers, scheduling, failover, model loading, and secure networking.

Through setup, troubleshooting, research, teacher feedback, and documentation, I now have a much clearer system model:

flowchart TD
    A[Student / OCS Client] -->|HTTPS| B[Public OCS Endpoint]
    B --> C[NGINX]
    C --> D[Python / FastAPI API]
    D --> E[OCS Broker]

    E --> F[(RDS / Durable State)]
    E --> G[(Redis / Live State + Queue)]
    E --> H[NetBird Private Network]

    H --> I[Mac Mini Pool]
    H --> J[GPU Rig 1]
    H --> K[GPU Rig 2]

    I --> L[Session / Context / Agent Workers]
    L --> M[GPU Scheduler]
    M --> J
    M --> K

    J --> N[llama.cpp / llama-server]
    K --> O[llama.cpp / llama-server]
    N --> P[Model Inference]
    O --> P
    P --> A

Loading

The architecture is intentionally split into layers so that each part has a clear responsibility:

Layer	Main Responsibility	Planned Components
Client / Web	Let students submit requests without needing to understand the infrastructure	OCS web client, HTTPS endpoint
Cloud Control Plane	Stable public entry point, API, identity, routing, durable state	AWS/OCS EC2, NGINX, FastAPI, broker, RDS
Real-Time Coordination	Track live workers, assignments, availability, queues, and locks	Redis
Private Network	Securely connect cloud services to on-premise machines	NetBird
Mac Mini Layer	Maintain working context, prepare requests, run agents, cache temporary project/session information	Linux, Docker, worker agent, monitoring, cache
GPU Layer	Load models and perform inference	Ubuntu, NVIDIA driver, CUDA-compatible environment, llama.cpp, llama-server, GGUF models
Scheduling	Decide which Mini and which GPU should receive work	Mini scheduler + GPU scheduler / broker logic

My main Ground Zero evidence is not only that I can use the tools, but that I used the tools to investigate, compare, document, redesign, and explain a real technical system.

---

1. Ground Zero Readiness Check

Overall Status

Ground Zero Area	Status	Evidence / Current Position
1. Understand the Challenge	✅ Ready	I understand that Ground Zero is about learning how to work through unfamiliar systems, not just completing setup steps. I have multiple troubleshooting examples and have documented the AI infrastructure research in GitHub issues.
2. My Development Environment	✅ Ready	I can work independently in VS Code, use Git/GitHub, edit Markdown/code, troubleshoot local tooling, and use remote Linux development environments.
3. My GitHub Workflow	✅ Ready	I can create issues, edit locally, commit, push, sync, use repository history, and use issues as technical documentation rather than only as task lists.
4. Forming the Team	🟡 Mostly Ready	The technical direction and shared project problem are clear. The next improvement is making team execution more systematic through owners, milestones, evidence expectations, and repeatable stand-up/checkpoint habits.
5. Beginning the Project	✅ Ready	We have moved beyond vague ideation. The project has research questions, an architecture, known hardware constraints, a phased implementation plan, and a concrete first end-to-end milestone.

Ground Zero Transition

flowchart LR
    A[Install / Configure Tools] --> B[Encounter Problems]
    B --> C[Investigate]
    C --> D[Test Solutions]
    D --> E[Document Results]
    E --> F[Compare Approaches]
    F --> G[Define Architecture]
    G --> H[Build MVP]
    H --> I[Measure + Improve]

    style G stroke-width:3px
    style H stroke-width:3px

Loading

The important transition for me is that I am no longer treating setup as the end goal. Setup now exists to support the next stage: building and testing the distributed OCS AI system.

---

2. Understand the Challenge

What I Think the Ground Zero Challenge Actually Was

The challenge was not just to get VS Code, Git, GitHub, a portfolio, or a development server working. The real challenge was learning to behave like a developer when the environment is unfamiliar and the answer is not already written down.

My process became:

Encounter → Investigate → Experiment → Solve → Document → Reflect → Improve

I demonstrated that process several times during the sprint.

Example: Local Jekyll / Ruby Tooling Problem

While working with the portfolio environment, bundle install failed because the system Ruby version was too old for the required ffi gem. The error was not a problem with my Python virtual environment even though the terminal showed that the venv was active. I had to separate the environments mentally: Python's venv does not replace macOS's Ruby runtime.

ffi-1.17.4-x86_64-darwin requires ruby version >= 3.0
Current Ruby: 2.6.10

That problem helped me better understand that a development environment is made of multiple independent runtimes and dependency managers, and that fixing the wrong layer wastes time.

Example: Remote Development Resource Problem

I also encountered a remote-development problem where a small Linux server became overloaded while using a heavy remote coding/AI extension. Instead of assuming the server itself was broken, I investigated what process was creating the load, removed the unnecessary extension, and reconsidered the remote-editor strategy for low-resource hosts.

That changed the question from:

“Why is SSH slow?”

into:

“What is the resource cost of my development tooling, and is that tooling appropriate for this machine?”

That mindset applies directly to the current project because the Mac Minis and GTX 1070 rigs are also constrained hardware. The project cannot simply assume that the newest or heaviest software stack is automatically the best stack.

---

3. My Development Environment

Current Working Environment

Area	What I Can Do Independently	Ground Zero Evidence
VS Code	Edit code/Markdown, use integrated terminal, work with repositories, use extensions, inspect errors	Used throughout portfolio and project work
Git	Stage, commit, inspect changes, sync work, recover from common repository problems	Used for class repositories and documentation
GitHub	Create issues, use issues for research/planning, review commits, work with repositories and project documentation	AI infrastructure issue/research documentation
Markdown	Build structured technical documentation using headings, tables, diagrams, checklists, code blocks, and links	Used for project issues and this Ground Zero review
Local Web Tooling	Work with Jekyll/GitHub Pages stack and troubleshoot dependency problems	Ruby/Bundler/ffi compatibility investigation
Linux / Remote Dev	SSH into systems, inspect processes/resources, troubleshoot services, adapt tooling to constrained hosts	Remote development troubleshooting
Server / Networking Tools	Understand reverse proxies, APIs, private networking, workers, queues, and infrastructure separation	OCS AI architecture planning

My Environment Strategy

My current strategy is to avoid treating my laptop as a one-off setup that only works because I happened to install the right things in the right order. I want the environment to be repeatable and understandable.

For the project, this means separating environments by purpose:

flowchart TD
    A[MacBook Development Machine] --> B[Git / GitHub]
    A --> C[Local Portfolio / Docs]
    A --> D[SSH / Remote Development]

    D --> E[AWS / OCS Control Plane]
    D --> F[Mac Mini Test Worker]
    D --> G[GPU Rig Test Node]

    B --> H[Versioned Configuration + Documentation]
    H --> E
    H --> F
    H --> G

Loading

The long-term goal is that important setup knowledge lives in repositories and documentation, not only in my memory or shell history.

---

4. My GitHub Workflow

I am comfortable using GitHub as more than a place to store finished code. During Ground Zero, I used issues as a way to expose my thinking and create a record that my team and teacher could respond to.

A strong example is the infrastructure research issue I created for the multi-GPU / Mac Mini direction:

• Research / setup issue: Initial Checkpoint CyberLord09/anvay_2025#49

My current GitHub workflow is:

flowchart LR
    A[Question / Problem] --> B[GitHub Issue]
    B --> C[Research + Plan]
    C --> D[Develop in VS Code]
    D --> E[Test]
    E --> F[Commit]
    F --> G[Push / Sync]
    G --> H[Update Issue with Evidence]
    H --> I[Teacher / Peer Feedback]
    I --> J[Refine Plan]
    J --> D

Loading

Why This Is Better Than My Starting Workflow

Earlier, I was more likely to solve the immediate technical problem and move on. My stronger workflow now is to capture:

• what I was trying to do,
• what failed,
• what I tested,
• what I learned,
• what decision I made,
• what is still unknown,
• and what evidence proves the result.

That makes the work usable by the rest of the team and gives me a much better record when the system becomes more complicated later.

---

5. Technical & Learning Evaluation

Technical Score Summary

Category	Average Self Rank
Tools & Development Environment (T01–T04)	4.0 / 5
Development & Creation (T05–T09)	3.4 / 5
Technical Awareness & Communication (T10–T12)	4.3 / 5
Overall Technical Average	3.8 / 5

I intentionally did not rank everything as a 5. My strongest evidence is in troubleshooting, architecture, technical communication, and evaluating approaches. Several areas are at 3–4 because I understand or can independently apply the skill, but I have not yet built the full distributed system described in the plan.

---

Tools & Development Environment

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
T01	Development Environment	4	—	—	I can independently work across my Mac development environment and remote Linux hosts, and I can troubleshoot runtime/dependency/resource issues instead of only following setup steps.
T02	VS Code	4	—	—	I use VS Code independently for code, Markdown, terminal workflows, Git, and remote development. I have also evaluated when a VS Code/extension setup is too heavy for a constrained machine.
T03	Git / GitHub	4	—	—	I independently use commits, pushes, repository workflows, and GitHub issues for technical documentation and planning. My next step toward 5 is creating more reusable automation/workflows for the team.
T04	Portfolio / GitHub Pages	4	—	—	I can work with the portfolio/Pages toolchain and diagnose build problems such as Ruby/Bundler dependency conflicts. I still want the environment to be more reproducible and less dependent on local setup details.

Reflection — Tools & Development Environment

My development environment skills improved most in diagnosis. I was already comfortable opening VS Code and editing files, but Ground Zero forced me to distinguish between different layers of a development environment. The Jekyll issue was a good example: the Python virtual environment was not relevant to the Ruby/Bundler failure, so the correct fix required understanding which runtime actually owned the dependency. I also learned that development tools themselves have resource costs. A remote server can be functioning correctly while an editor extension makes it unusable. I now look at processes, runtimes, versions, logs, and system constraints before changing random settings. That is a much more useful skill for this project than simply knowing a list of setup commands.

---

Development & Creation

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
T05	Tools & Equipment Hacks	4	—	—	I can adapt tools and infrastructure to constrained hardware, compare approaches, and design around limitations. The next step is proving more of the design on physical Minis/GPUs.
T06	Portfolio / Blogging Hacks	3	—	—	I can create and maintain useful Markdown documentation and portfolio content independently, but advanced portfolio/blog customization has not been the main focus of my sprint.
T07	Theme / Style / Layout	3	—	—	I can structure readable pages/issues with tables, diagrams, sections, and hierarchy, but I have not spent this sprint building a major original theme or UI system.
T08	JavaScript / Coding Challenges	3	—	—	I can independently work through coding tasks, but the strongest Ground Zero evidence this sprint is infrastructure/orchestration rather than a large new JavaScript implementation.
T09	AI Orchestration	4	—	—	I can now analyze and explain the control plane, Mini worker layer, GPU inference layer, state separation, networking, and two-stage scheduling problem. I am not ranking this 5 because the broker and scheduler are not yet implemented end-to-end.

Reflection — Development & Creation

The most important thing I created during Ground Zero was not a single code feature; it was a better system design. The early idea was much closer to “students connect to compute.” Through iteration, the project became a hybrid architecture with a stable cloud control plane, Redis for live state, persistent storage for durable state, NetBird for private infrastructure connectivity, Minis for sessions/context/agents, and GPU rigs for inference. I also learned that orchestration needs to happen at more than one layer. The system has to choose a Mini for a session and then choose GPU capacity for an inference request. That creates real engineering questions around health checks, queues, model locality, failover, and fairness. My next step is to convert that design knowledge into a minimal working broker instead of continuing to add architecture complexity on paper.

---

Technical Awareness & Communication

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
T10	Tech / Cyber Growth	4	—	—	I expanded from individual Linux/networking skills into thinking about distributed state, orchestration, resource scheduling, and reliability across many hosts.
T11	Learning Through Mistakes	5	—	—	I consistently use errors and failed assumptions to change my model of the system, document the cause, and improve the approach rather than only patch the symptom.
T12	Tech / Cyber Talk	4	—	—	I can explain the architecture at multiple levels—from a simple request flow to detailed control-plane/state/scheduler tradeoffs. My next step is becoming equally clear when presenting benchmark results and tradeoff decisions.

Reflection — Technical Awareness & Communication

My biggest technical growth was learning to explain why the architecture is organized the way it is. I can now explain why students should normally use a public HTTPS endpoint instead of joining the infrastructure network directly; why NetBird is for private infrastructure connectivity; why Redis should track fast live state while RDS stores durable state; why a Mini should hold disposable working context instead of becoming the permanent source of truth; and why the GTX 1070 generation forces us to research the runtime instead of assuming a modern serving stack will work. The mistakes and confusing parts were useful because each one exposed a missing assumption. My communication also improved because I started using diagrams, tables, and GitHub issues to make those assumptions visible to my team and teacher.

---

6. Technical Evaluation Follow-Up

Before the Evaluation

• I reviewed the Ground Zero checklist.
• I reviewed my technical evidence from the sprint.
• I entered self-rankings before peer/teacher calibration.
• I can support the rankings with specific examples.
• I identified technical areas that still need improvement.

Retrospective Question

What can I do now as a developer that I could not do at the beginning of this sprint?

At the beginning of the sprint, I could work with many of the individual technologies, but I did not have a strong model for how this specific OCS AI system should be divided. I can now take a vague requirement like “make these Minis and GPU rigs useful for students” and break it into architecture layers, interfaces, state types, research questions, failure cases, and testable milestones. I can explain the difference between the public control plane and private compute plane, define what belongs in Redis versus durable storage versus a Mini's working cache, identify why the broker needs health information, and describe the two-stage scheduling problem. I can also turn teacher feedback into a revised system diagram and a phased implementation plan instead of treating feedback as a list of disconnected changes.

Strongest Technical Evidence

The technical evidence I am most proud of:
The architecture/research issue for the OCS AI infrastructure because it shows the evolution from hardware setup into a real distributed system design. It contains networking, worker responsibilities, GPU constraints, state management, scheduling questions, and a production/development split.

The biggest technical problem I solved:
The biggest conceptual problem was deciding what each machine should actually be responsible for. The solution was to stop treating all machines as equivalent compute nodes: AWS becomes the stable control plane, Minis become disposable session/context/agent workers, and GPU rigs become specialized inference capacity.

The technical skill I most need to improve:
Turning infrastructure architecture into working distributed services with measurable behavior, especially health checks, queues, scheduling, failover, and observability.

My next technical learning goal:
Build the smallest end-to-end OCS AI request path and collect evidence for every hop before scaling the system.

---

7. Professional Evaluation

Professional Score Summary

Category	Average Self Rank
Core Behaviors (P01–P03)	4.0 / 5
Collaboration (P04–P06)	4.0 / 5
Professional Skills (P07–P10)	4.3 / 5
Overall Professional Average	4.1 / 5

These rankings reflect that I am generally independent and highly engaged, but I still have room to improve consistency in team process, timeliness, and turning large technical plans into smaller completed deliverables.

---

Core Behaviors

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
P01	Attendance / Tardy	3	—	—	My attendance/timing was not perfect, so I am not ranking this as a 4 or 5. I did make an effort to recover missed context and keep my project work moving independently.
P02	Work Habits	4	—	—	I consistently investigate technical problems, document work, and continue beyond the minimum setup task. I can improve by reducing context switching and finishing smaller milestones sooner.
P03	Integrity	5	—	—	My documentation distinguishes what is working, what is proposed, what is uncertain, and what still needs testing. I do not want architecture diagrams to imply implementation that does not yet exist.

Reflection — Core Behaviors

My strongest core behavior was taking responsibility for work even when the problem was unclear. I did not wait for every command or architecture decision to be given to me. I researched, tested, created issues, and then used feedback to update the plan. The main improvement I need is converting that independence into more consistent delivery. I can spend a lot of effort understanding the full system, which is useful, but professional work also requires choosing the smallest valuable next step and completing it. My next sprint needs to show more completed vertical slices, not only strong research.

---

Collaboration

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
P04	Communication	4	—	—	I communicate technical questions and plans through detailed GitHub issues, diagrams, and direct questions. I can improve by making action items shorter and more owner-specific for teammates.
P05	Help Seeking	4	—	—	I ask for feedback when I reach uncertainty and use that feedback to change the design rather than only asking for answers.
P06	Mentoring / Advocacy	4	—	—	My documentation is designed to help teammates understand the system and avoid repeating setup/research work. I can move toward 5 by pairing more intentionally and helping teammates own parts of the architecture.

Reflection — Collaboration

I learned that good technical communication is not the same as writing a lot. The useful part is making the system understandable enough that another person can make a decision or continue the work. The diagrams and issue documentation helped because the AI infrastructure has many components that are easy to confuse. For example, separating RDS, Redis, Mini working state, and GPU inference responsibilities gives the team a shared vocabulary. My next collaboration improvement is to make documentation more executable: every major section should lead to a task, owner, success condition, or experiment instead of remaining only an explanation.

---

Professional Skills

ID	Area	Self Rank	Peer	Teacher	Evidence / Reasoning
P07	Timeliness	3	—	—	I get important work done, but I can improve at turning large research efforts into smaller completed checkpoints earlier.
P08	Persistence	5	—	—	I continue investigating when setup, dependencies, remote development, or architecture becomes difficult, and I usually come away with a clearer technical explanation.
P09	Organization	4	—	—	I use issues, diagrams, tables, architecture layers, and phased plans to organize complex work. The next improvement is tighter task ownership and milestone tracking.
P10	Engagement	5	—	—	I am actively exploring the project beyond basic requirements and contributing research questions, technical tradeoffs, and possible system designs.

Reflection — Professional Skills

Persistence is probably my strongest professional skill in this sprint. When a setup path breaks, I usually keep investigating until I understand the actual layer causing the problem. That same persistence helped with the architecture because the first design was not automatically the final design. I kept revising the role of the Minis, cloud endpoint, broker, state storage, and GPU scheduling as the requirements became clearer. The main thing I need to balance is persistence with scope control. A developer can keep improving a design forever. My next sprint needs stricter milestones so that research produces working evidence on a predictable schedule.

---

16. Professional Retrospective

What did I learn about myself as a developer and teammate that I could not have learned from a grade alone?

I learned that I am strongest when the problem is ambiguous and needs to be broken apart, but that strength can also become a weakness if I keep expanding the design instead of locking in a small implementation milestone. I naturally want to understand why every layer exists and how the full system should eventually work. That helped me turn the GPU-rig idea into a more complete distributed architecture, but the next level of growth is knowing when the design is good enough to test. A grade would only show whether the final task was complete; the sprint showed me that my real development challenge is balancing depth of understanding with speed of execution.

---

8. Next Sprint Commitment

One professional behavior I will improve

Timeliness through smaller milestones. I will break large infrastructure tasks into pieces that can be demonstrated in one checkpoint instead of waiting until an entire subsystem is finished.

One technical skill I will improve

Distributed service implementation and observability. I want to move from diagrams to working heartbeats, worker registration, queue state, job assignment, logs, and measurable failure behavior.

One way I will contribute more effectively to my team

I will turn the architecture into clearly owned workstreams with acceptance criteria, so teammates can independently contribute without needing to understand the entire system first.

Evidence I will collect during the next sprint

• GitHub issue for each major implementation milestone
• Commits / pull requests tied to issues
• Screenshot or log showing NetBird peer connectivity
• Working llama-server API response from the GPU rig
• GPU benchmark table
• Mini heartbeat / registration evidence
• Redis worker-state screenshot or CLI output
• End-to-end request trace
• Latency measurements for each major hop
• Failure test: stop a Mini or GPU worker and record behavior
• Short demo showing the complete request flow

---

9. Questions I Want the Next Sprint to Answer

1. Networking: How often does NetBird establish direct P2P paths in our real school/home/cloud topology, and how much performance do relays cost?
2. GPU runtime: Which llama.cpp build/model/quantization combinations are actually useful on GTX 1070 hardware?
3. Mini capacity: How many simultaneous active sessions can one Mini reasonably manage if inference is offloaded to the GPU rigs?
4. Scheduler: Is least-busy scheduling enough as a baseline, or does model locality produce a meaningful performance advantage?
5. Queueing: What should the user experience be when every GPU is busy?
6. Failure: How quickly can the broker detect a dead Mini or GPU worker?
7. Session recovery: How much working context must be reconstructable so a session can move to another Mini?
8. Rig failover: What should happen if Rig 1 goes offline? Can the development rig be promoted cleanly?
9. Observability: What minimum metrics make it possible to debug the system without SSHing into every machine?
10. Scale: At what point do the Minis, network, queue, or GPUs become the bottleneck?

---

10. Final Ground Zero Reflection

Ground Zero was successful for me because I am leaving it with more than a working editor or repository. I now have a stronger method for approaching technical uncertainty.

The biggest lesson is that setup problems and architecture problems are both learning evidence when I can explain the decision that came out of them. The Ruby dependency failure taught me to identify the correct runtime layer. The remote-development problem taught me to consider the cost of the tools themselves. The AI infrastructure planning taught me to separate durable state, fast state, working state, orchestration, and inference instead of putting every responsibility on the same machine.

The project is also at a better starting point. The goal is no longer “make 30 Minis and 16 GPUs do something with AI.” The goal is to build and evaluate a small distributed AI infrastructure platform where:

• AWS / OCS services provide the stable control plane,
• RDS keeps durable state,
• Redis coordinates live state and queues,
• NetBird privately connects infrastructure,
• Mac Minis manage sessions, context, caching, and agent work,
• GPU rigs provide interchangeable inference capacity,
• and the broker turns all of those independent machines into one usable system.

My next step is to stop increasing the architecture's complexity and prove the smallest version of it. If I can demonstrate a single request moving from client → broker → Mini → GPU → model → response, with logs and measurements at every layer, then we will have a real foundation that can be scaled and improved instead of only a plan.

---

Ground Zero Close-Out

Current status: ✅ Ready to move from onboarding into project development

Primary next milestone: One complete end-to-end inference request through the planned OCS architecture.

What I want my next checkpoint to prove:

I can take the distributed architecture I researched during Ground Zero and turn it into a small, measurable, working system.