This document is the starting point for understanding how the Samchis Web Development School platform works from a user’s perspective.

It is intentionally conceptual, not technical.

You will not find:

• Code-level explanations
• Implementation details
• Admin-only operations
• Internal security mechanics

Instead, this manual helps you understand:

• What the platform is designed to do
• How the major parts of the platform fit together
• How users progress over time
• Why certain actions are gated, limited, or restricted
• Where to go next depending on your goals

This manual is written for:

• New users trying to orient themselves
• Learners progressing through structured content
• Contributors using tools like Dev Space
• Community participants engaging with projects or governance
• Subscribers evaluating access, limits, and upgrades

Each section in this document is derived from an internal system document.

Those internal documents define how the system works.

This manual explains what that means for you as a user.

You do not need to read this manual in one sitting.

It is designed to be read in order, but also to be revisited as your role and activity on the platform evolve.

The Samchis Web Development School platform exists to provide a controlled, credible, and progression-based environment for learning web development and participating in a structured digital community.

It is not designed to be:

• A casual blog
• A generic learning management system
• An open file-sharing platform
• A social network driven by engagement metrics

Instead, the platform is intentionally built as a learning and creation ecosystem, where access, capability, and authority are earned over time.

At its core, the platform is guided by one overriding principle:

This means:

• Accuracy and trust matter more than rapid growth
• Fair access matters more than frictionless access
• Clear rules matter more than silent flexibility

The platform is designed around systems, not pages.

Each system exists to serve a specific purpose and to interact safely with other systems.

From a user perspective, this philosophy results in:

• Clear boundaries between public access and authenticated access
• Visible explanations when actions are limited or unavailable
• Progressive unlocking of capabilities as you move forward
• Consistent behavior across learning, content, community, and tools

Learning on this platform is not accidental.

It is structured, intentional, and auditable.

Creation on this platform is not anonymous.

Identity, accountability, and credibility are preserved.

Community participation is not uncontrolled.

Trust, moderation, and escalation paths are built in.

As a user, this means:

• You are always told why something is allowed or restricted
• You are never silently promoted or blocked
• Your progress is recognized through defined stages
• Your actions contribute to a system designed to last

All other user-facing systems — learning, Dev Space, content, subscriptions, identity, and participation — exist to serve this foundational purpose.

This platform behaves like a controlled building, not an open street.

You do not “enter everything at once” just because you created an account. Instead, the platform activates your access in stages, and each stage exists for a reason: fairness, safety, credibility, and consistent learning quality.

Think of the Core Platform as the “rules of reality” for the entire school.

Every other system (Learning, Dev Space, Billing, Trust, Admin) depends on it.

If the Core Platform says “not yet,” every other system must respect that.

The Core Platform is built on four non-negotiable ideas:

Progressive User Lifecycle (You Become Active in Steps)

• Registered — You created an account, but your access is intentionally limited.
• Email Verified — You confirm your email using an OTP-based verification flow. Until this is complete, you are blocked from protected systems.
• Profile Completed — You complete required profile data (identity + demographic context). This prevents ghost accounts and ensures the platform can treat users fairly and consistently.
• Subscribed (optional, level-based) — Subscription is not just payment history; it is an access state that is evaluated during platform usage.

These stages exist to prevent abuse, reduce impersonation risk, and ensure every downstream feature works with complete, reliable user state.

Server-Side Authority (The Backend Decides, Not the UI)

On this platform, access is not determined by what a button looks like.

• Middleware (gates at the route level).
• Services (rule engines and single sources of truth).

Only server-side checks can reliably protect learning resources and tools.

So when something is locked, it is not frontend drama. It is an enforced rule.

Subscription as a Runtime State (Not a Static Label)

• A subscription can expire and be downgraded automatically.
• The platform does not rely on what you paid before.
• It relies on what your access state is right now.

Learning resources remain discoverable while access is enforced fairly.

Security by Configuration (Rules Are Centralized)

Security behavior is consistent and configurable through centralized services.

This reduces security drift where rules become inconsistent over time.

Why This Section Matters

If you understand this Core Platform structure, the rest of the manual becomes much easier.

You will always know why something is allowed or restricted at any moment.

Learning on the Samchis Web Development School platform is not passive, instant, or cosmetic.

This platform does not measure learning by:

• Time spent watching videos
• Pages visited
• Buttons clicked
• Attendance alone

Instead, learning is defined by demonstrated ability, evaluated through a structured progression system that is enforced consistently for every user.

This section explains how learning works, how progress is measured, and why the rules around attempts, submissions, and reviews are intentionally strict.

What Learning Means on This Platform

Learning here is outcome-based.

That means:

• You are given structured challenges (assignments)
• You attempt those challenges under defined constraints
• Your work is reviewed and evaluated
• Your progress is recorded permanently
• Completion is earned, not implied

You do not “complete” the school by consuming content alone.

You complete it by proving competence.

Assignments: The Core Unit of Learning

Assignments are the backbone of the learning system.

Each assignment:

• Has a clear objective
• Defines what you are expected to demonstrate
• May require written work, practical work, or a project
• Has a defined scoring system
• Has a pass threshold
• Has a limited number of attempts

Assignments are not optional checkpoints.

They are the mechanism through which learning is verified.

If an assignment is active, it matters.

Attempts Are Limited — By Design

Every assignment has a maximum number of attempts.

Attempts are counted when you start an assignment, not when you submit.

Once an attempt is used, it cannot be undone or reset.

This is intentional.

Unlimited retries:

• Encourage guessing
• Reduce seriousness
• Undermine credibility
• Make certification meaningless

Limited attempts:

• Encourage preparation
• Encourage focus
• Reflect real-world constraints
• Protect the value of passing

If you exhaust your attempts, the system will not allow further starts.

This is not punishment.

It is part of maintaining a fair and credible learning environment.

Submissions & Reviews

When you submit an assignment, you are submitting a claim:

That claim must be evaluated.

For this reason, submissions enter a review state.

Reviews are performed manually.

Outcomes are deliberate, not automatic.

There are two types of submissions on the platform:

• Assignment submissions
• Project review submissions (from Dev Space)

Each submission type has strict rules:

• Only one pending submission is allowed at a time
• Duplicate or parallel submissions are blocked
• Reviews must be completed before further progress

These constraints protect both learners and the integrity of results.

Scoring, Passing & Progression

Each assignment is graded using a defined scoring system.

To pass an assignment:

• It must be reviewed
• A score must be recorded
• The score must meet or exceed the pass threshold

There is no concept of “partial pass” or “silent completion”.

Your progress is tracked transparently:

• Assignments not started
• Assignments in progress
• Assignments submitted
• Assignments passed
• Overall completion percentage

Progress is cumulative and irreversible by design.

This ensures that achievements remain meaningful.

Certificates: Proof, Not Decoration

Certificates on this platform are not issued for participation.

They are issued only when all required assignments are passed.

This means:

• No skipped requirements
• No automatic issuance
• No retroactive adjustments
• No silent exceptions

When a certificate is issued, it represents verified completion.

It reflects evaluated work.

It is traceable and auditable.

It is designed to be defensible outside the platform.

Certificates are the output of the learning system, not the goal itself.

The goal is mastery.

The certificate is evidence.

Why This System Is Strict

• Learners deserve credentials that mean something
• Reviewers deserve a system that respects their effort
• Employers and collaborators must be able to trust outcomes
• The platform must protect its long-term credibility

Relaxing these rules would make learning easier in the short term, but would destroy trust in the long term.

As a user, this structure exists to protect your work and your progress, not to block you arbitrarily.

What to Expect as a Learner

• Clear requirements before starting assignments
• Visible attempt limits
• Explicit submission states
• Waiting periods during review
• Transparent outcomes
• Permanent progress records

If something feels “strict”, it is usually because the system is enforcing fairness, not because something is wrong.

Not everything you learn on this platform comes in the form of assignments or hands-on projects.

The Samchis Web Development School platform includes a dedicated Content Engine designed to deliver structured knowledge, guidance, clarification, and verification in written and media-supported formats.

This system exists to support learning, preserve institutional credibility, and ensure that information shared on the platform remains authoritative, traceable, and consistent.

What the Content Engine Is — and Is Not

The Content Engine is responsible for all non-assignment, non–Dev Space knowledge delivery.

It exists to:

• Explain concepts in depth
• Clarify expectations and rules
• Provide official guidance
• Correct misinformation
• Supplement video lessons with structured text
• Maintain trust and editorial consistency

It is intentionally separate from:

• The Learning Engine (assignments, scoring, certificates)
• Dev Space (hands-on project execution)
• Billing logic (access is enforced, but not defined here)

This separation ensures that learning progress, editorial content, and practical execution can evolve independently without breaking each other’s rules.

The Four Content Types You Will See

The Content Engine is made up of four clearly defined content types.

Each serves a different purpose and should be understood differently by users.

Posts — Learning Companion

Posts are structured written lessons, explanations, updates, and learning companions that support your development.

They are not casual blog posts.

Posts are used to:

• Break down concepts in written form
• Expand on video lessons
• Share curriculum updates
• Provide structured explanations
• Encourage discussion and clarification

From a user perspective:

• Some posts are free
• Some posts require a subscription level
• Gated posts show previews before upgrade prompts
• Posts support comments for learning discussion

Posts do NOT:

• Track learning progress
• Unlock certificates
• Replace assignments

Statements — Instructor Notes

Statements are official, authoritative documents issued by instructors or the institution.

They are treated as formal guidance, not articles or announcements.

Statements exist to:

• Clarify policies or expectations
• Address important issues
• Provide official interpretations
• Communicate decisions or positions

From a user perspective:

• Statements are intentional and traceable
• They are timestamped and issued deliberately
• They may include summaries and action points
• They are gated by subscription level where required
• They support discussion through comments

Statements are not casual.

If something appears as a Statement, it represents an official position.

Fact Checks — Reality Checks

Fact Checks exist to verify claims, correct misinformation, and establish technical or factual truth.

They are intentionally:

• Public
• Accessible without subscription
• Evidence-driven
• Authority-focused

Fact Checks:

• Present a claim
• Issue a verdict (true, false, misleading, etc.)
• Provide explanations and evidence
• Link to sources where applicable

Fact Checks are not opinions and are not lessons.

They exist to preserve credibility and shared understanding.

Media Items — Video Parity

Video lessons and media items follow the same access philosophy as Posts and Statements.

This means:

• Subscription level governs access
• Locked users see previews
• Upgrade paths are explicit
• Access behavior is predictable

This parity ensures that users experience consistent rules regardless of whether content is written or video-based.

Comments, Discussion & Identity

All major content types support comments.

Comments exist to:

• Ask clarifying questions
• Discuss interpretations
• Support community learning
• Interact with instructors

However:

• Comments are tied to user identity
• Anonymous posting is not allowed
• Visibility rules are enforced
• Moderation exists
• Abuse has consequences

Discussion is encouraged.

Disorder is not.

Why This System Is Structured This Way

The Content Engine is designed to protect:

• Learning clarity
• Editorial integrity
• Institutional credibility
• User trust

Mixing casual posts, official guidance, verification, and lessons into a single “blog” would undermine all of these goals.

By separating content types and enforcing clear rules, the platform ensures that users always know:

• What kind of information they are reading
• How authoritative it is
• Whether access is gated
• How it relates to their learning journey

What to Expect as a User

• Clear labeling of content type
• Predictable access behavior
• Transparent upgrade prompts where applicable
• Consistent editorial tone
• Opportunities for discussion without loss of control

If content feels structured or deliberate, that is intentional.

The platform treats knowledge as something to be preserved, not casually published.

Dev Space is the structured practice environment of the Samchis Web Development School.

It allows you to build real web projects directly in your browser while operating within clearly defined learning boundaries.

Dev Space is powerful by design — and intentionally constrained for discipline, fairness, and system stability.

What Dev Space Is Designed For

• Creating structured HTML, CSS, and JavaScript projects
• Practicing lessons inside a controlled learning environment
• Previewing frontend code in isolation
• Saving snapshots of project states
• Submitting work for structured review
• Participating in platform challenges
• Learning disciplined project organization

Dev Space exists to train thinking, not to simulate unlimited tooling.

What Dev Space Is Not

• A backend execution environment
• A public hosting platform
• A desktop IDE replacement
• A file system with unrestricted server access
• An unlimited project storage system

Dev Space focuses strictly on frontend learning inside a sandboxed environment.

Project Slots & Review Slots

Dev Space operates with two distinct limit systems:

• Project slots — how many active projects you may own
• Review slots — how many expert reviews you may submit per month

These limits depend on your subscription plan and are clearly displayed in your Dev Space dashboard.

Project slots limit how many projects you can create.

Review slots reset monthly and limit how many expert reviews you can request.

These are separate systems. Creating projects does not consume review slots. Submitting for review does not consume project slots.

Project Structure & File System

Each project is a structured container of files.

• Projects belong only to the authenticated user
• Projects are private by default
• Files are stored internally, not on a public server
• File paths are normalized for security
• Direct server access is never granted

All file rendering is sandboxed to prevent unsafe execution.

Editing & Rendering Engine

Dev Space uses a controlled rendering engine to display your project.

• The entry file is typically /index.html
• Rendering is sandboxed and isolated
• External backend calls are restricted
• File access is resolved internally through the platform

This ensures fairness, predictability, and security during review.

Snapshots & Version Control

• Snapshots freeze a project state
• Snapshots can be labeled
• Restoring a snapshot overwrites current project state
• Snapshot counts depend on subscription level

Snapshots encourage safe experimentation while preventing reckless overwrites.

Templates & Project Instantiation

Templates are administrator-created structured starter projects.

• Templates can be previewed before use
• Instantiating a template creates a new personal project
• Template files become editable once instantiated
• Some templates require higher subscription tiers

Templates provide structure, not shortcuts.

Submissions & Review Rules

When submitting for expert review:

• Only one pending review is allowed per project
• Monthly review limits apply
• A project under review cannot be resubmitted
• Each submission consumes one review slot

Submission history is recorded and visible in your dashboard.

Review outcomes may include approval, rejection, or feedback requiring revision.

Sharing & Read-Only Access

• Projects may be shared via unique preview links
• Shared previews are read-only
• Viewers cannot edit your code
• Sharing availability depends on plan level

Sharing exists for feedback and collaboration, not for public hosting.

Why Limits Exist

• To protect reviewer capacity
• To ensure fairness across users
• To prevent abuse of system resources
• To encourage deliberate practice
• To maintain system performance and stability

Limits are structural safeguards — not punishments.

Dev Space rewards focus, iteration, preparation, and disciplined improvement.

The Samchis Web Development School platform uses a subscription-based access model.

This means payment is not just about “buying content.”

It determines what you can access, how much you can do, and when access changes over time.

Understanding this system prevents confusion, frustration, and incorrect expectations.

What Payment Means on This Platform

On this platform:

• Payment activates or changes your subscription level
• Subscription level determines access authority
• Access is evaluated continuously, not permanently granted
• Payment history does NOT automatically guarantee access

In simple terms:

You are not paying for files or pages.

You are paying for permission to use systems at a certain level.

Plans & Levels (The Authority Model)

Each plan on the platform has a level.

From a user perspective:

• Higher levels unlock more features and higher limits
• Lower levels remain visible, but restricted
• You can always see what exists, even if you can’t use it yet

Plans define access to:

• Learning assignments
• Dev Space limits (projects, snapshots, submissions)
• Templates
• Media and premium content
• Certificates eligibility

Plans are designed to be:

• Clearly labeled
• Comparable
• Transparent before payment

You are never expected to guess what a plan does.

Public Pricing (Discovery Without Pressure)

The pricing page is fully public.

This allows you to:

• Explore all available plans
• Compare features
• Understand progression paths
• Decide when to upgrade

Important rule:

Browsing pricing does not initiate payment.

It exists to inform, not to pressure.

Upgrading Your Plan

When you choose to upgrade:

• You must be logged in
• Your current plan status is shown
• Lower or equal plans are disabled
• Only valid upgrade paths are allowed

During upgrade:

• You choose a plan and duration
• You choose a payment method
• The platform explains what will change

Upgrades are explicit actions.

Nothing upgrades silently.

Payment Methods (What Users Should Expect)

The platform supports:

A) Automated Online Payments

• Processed instantly
• Subscription activates immediately after verification

B) Manual Payments

• Proof is submitted
• Payment is reviewed by an administrator
• Access activates only after verification

Manual payments exist to support users without immediate online payment access.

They are slower by design to preserve trust.

Subscription Behavior Over Time

Subscriptions are time-bound.

This means:

• Every subscription has a start and end date
• Expired subscriptions downgrade automatically
• Renewals extend access
• Upgrades apply immediately
• Downgrades may be scheduled after expiry

From a user perspective:

You will not be silently removed.

You will not be silently upgraded.

Access changes are predictable and visible.

If access changes, the platform explains why.

Your Billing Dashboard

Your billing dashboard allows you to:

• View payment history
• See subscription status
• Track expiry dates
• Download verified invoices

Important rule:

You cannot mutate billing data yourself.

This protects financial integrity and auditability.

Invoices & Records

Invoices are generated from verified payments.

As a user:

• You can download invoices for completed payments
• Invoice data reflects real payment state
• Pending or rejected payments do not produce invoices

This ensures:

• Accurate financial records
• Clear proof of payment
• No fabricated billing history

Why the Platform Is Strict About Billing

Billing rules exist to protect:

• Users
• Reviewers
• Administrators
• The credibility of certificates and learning outcomes

The platform does not allow:

• Self-verification of payments
• Access without valid subscription state
• Hidden plan overrides
• Manual tampering with access levels

These rules ensure fairness across all users.

What to Check Before Upgrading

Before upgrading, users should always consider:

• Which features they need now
• Which limits affect them most
• Whether they are actively using learning tools
• How long they intend to stay active

Upgrading is optional.

Progress is encouraged, not forced.

The Samchis Web Development School platform is built on a simple belief:

Learning, participation, and community only work when trust is protected.

This platform assumes:

• Real humans participate
• Abuse is possible
• Authority must be accountable
• Credibility must be defendable

Every trust rule you encounter exists to protect users, learning outcomes, and the long-term integrity of the platform.

Why Identity Matters Here

On this platform, identity is not cosmetic.

Certain actions require confidence that:

• One person equals one account
• Decisions are tied to real humans
• Abuse cannot be repeated anonymously

This is why:

• Identity is progressive
• Some actions unlock only after verification
• Authority is never anonymous

Identity does not mean exposure.

It means accountability.

Identity Verification (When Required)

Some platform actions require identity verification.

From a user perspective:

• Verification is optional until required by a feature
• You are clearly told when verification is needed
• Evidence is reviewed by administrators
• Evidence is not stored permanently

Key guarantees:

• One verification per user per type
• Evidence is purged after a decision
• Verification outcomes are logged
• Logs cannot be altered or deleted

Verification exists to prevent:

• Duplicate accounts
• Voting abuse
• Governance manipulation
• False reporting

Community Participation & Governance

The platform supports structured community participation, including elections and collective decision-making.

These systems are designed to:

• Be visible
• Be auditable
• Be resistant to manipulation

From a user perspective:

• Some elections are public
• Some elections require verification
• Votes cannot be changed after submission
• Disputes are resolved through audit logs

This ensures:

• One person, one vote
• No silent vote tampering
• Clear outcomes

Help Desk & Reporting (Safe Escalation)

When something goes wrong, users need a safe, structured way to escalate.

The Help Desk exists to:

• Request support
• Report issues or abuse
• Communicate with administrators

Rules exist to protect both sides:

• Reports are tied to identity
• Abuse is discouraged
• Evidence is handled securely
• Conversations are controlled and traceable

Attachments are:

• Scanned for threats
• Linked to a case lifecycle
• Deleted if unsafe

You are never expected to handle serious issues publicly.

Security Logging (What Is Recorded)

The platform records security-relevant events to protect users and systems.

From a user perspective:

• Logins are recorded
• Verification actions are recorded
• Suspicious activity is noted
• Logs support investigations

Important boundaries:

• Logs are not used for surveillance
• Logs are not sold or shared
• Logs are retained only for security and accountability

This ensures incidents can be explained, not guessed.

Abuse Prevention (Why Limits Exist)

Some limits feel strict until you understand their purpose.

Examples:

• Registration limits prevent account farming
• Submission limits protect reviewers
• Verification gates prevent manipulation
• Rate limits prevent automation abuse

These rules:

• Apply equally
• Are enforced consistently
• Are logged
• Are reviewable

Abuse prevention is layered by design.

No single rule is relied on alone.

Admin Accountability (Important Guarantee)

Administrators have authority — but not invisibility.

All sensitive admin actions are:

• Logged
• Timestamped
• Traceable
• Reviewable

This protects users from:

• Silent decisions
• Arbitrary enforcement
• Unaccountable power

Trust flows both ways.

What Users Should Expect

As a user, you should expect:

• Clear explanations when actions are gated
• No silent privilege escalation
• No anonymous authority
• Predictable enforcement
• Safe escalation paths

If a rule exists, it exists to protect:

• Learning credibility
• Fair access
• Community integrity
• Long-term platform trust

Authentication and access control define who you are, what you can do, and when you are allowed to do it on the platform.

These rules exist to:

• Protect user accounts
• Prevent privilege abuse
• Ensure fair access
• Maintain trust across learning and community systems

They are enforced consistently across the entire platform.

Authentication: Proving Who You Are

Authentication answers one question:

“Is this really you?”

On this platform:

• You sign in using email and password
• Your email must be verified before activation
• Sessions are managed securely on the server
• Suspicious behavior can trigger safe logout

Until authentication is complete:

• Protected features remain inaccessible
• Learning, Dev Space, and participation are blocked

Authentication is identity proof, not trust.

Trust is earned later.

Session Safety & Runtime Security

Once signed in, your session is actively protected.

From a user perspective:

• Sessions are refreshed securely on login
• Sessions are destroyed on logout
• Unexpected changes (like IP shifts) may be detected
• You may be logged out if risk is detected

If this happens:

• You are redirected safely
• You receive a clear, non-technical notice
• No data is lost
• No silent enforcement occurs

These checks exist to protect your account, not to inconvenience you.

Authorization: Limiting Capability

Authorization answers a different question:

“What are you allowed to do?”

On this platform:

• Access is controlled by roles and rules
• Having an account does not grant universal access
• Each section enforces its own permissions

Examples:

• Viewing content ≠ editing content
• Submitting work ≠ reviewing work
• Participating ≠ moderating

If you do not have permission, access is denied clearly.

There is no implied authority.

Roles & Permissions (User View)

Roles define where you can operate.

Rules define what you can do there.

As a user:

• Your default role allows learning and participation
• Elevated roles unlock moderation or governance features
• Roles do not bypass subscription or identity rules

Having a role does not mean:

• Unlimited power
• Unrestricted access
• Freedom from accountability

Roles grant access.

Rules constrain behavior.

Identity-Locked Actions

Some actions require more than login.

Before you can:

• Vote in elections
• Submit reports
• Participate in governance
• Open certain helpdesk cases

You must:

• Complete your identity profile
• Lock your identity state
• Complete verification if required

This ensures:

• One person = one action
• No anonymous authority
• Clear accountability

Admin Access (User Guarantees)

Administrators have elevated access — but not unchecked power.

From a user perspective:

• Admin access is role-gated
• Admin actions are logged
• Admin decisions are reviewable
• No admin action is invisible

This protects users from:

• Silent decisions
• Arbitrary enforcement
• Abuse of authority

Authority is constrained by design.

Failure, Blocking & Recovery

When access is denied:

• The platform responds correctly
• No sensitive information is exposed
• Messages remain human-readable

When recovery is possible:

• Clear retry paths are provided
• Escalation options exist
• Users are not left guessing

Security never fails silently.

It explains itself.

What Users Should Understand

• Why login is enforced strictly
• Why permissions vary by feature
• Why some actions unlock later
• Why roles don’t override rules
• Why access is predictable, not arbitrary

Authentication proves identity.

Authorization limits capability.

Trust is earned through behavior and verification.

The Media Library is your controlled storage space inside the platform.

It allows you to upload and manage media files that support your learning, Dev Space projects, and portfolio presentation.

However, it is not an unlimited cloud drive.

It is a structured, subscription-aware storage system designed to balance flexibility with fairness.

What the Media Library Is For

The Media Library allows you to:

• Upload images
• Upload videos (depending on plan)
• Rename files for clarity
• Delete files you no longer need
• Copy public URLs for use in Dev Space or elsewhere
• Embed media into your projects

Each uploaded file belongs to your account.

Other users cannot access or modify your media unless you explicitly share the URL.

What the Media Library Is Not

The Media Library is not:

• An unrestricted file hosting service
• A general backup system
• A place for unrelated large data storage
• A streaming platform
• A file-sharing system between users

Files are meant to support learning and project work.

Abuse or misuse may result in restrictions.

Plan-Based Storage Limits

Media uploads are controlled by subscription level.

From a user perspective:

• Free users can upload a limited number of images
• Basic users can upload more images
• Advanced and Elite users unlock higher limits and video uploads
• Admin-level roles may have expanded limits

Limits apply to:

• Number of images
• Number of videos
• Maximum file size

If you reach your limit:

• Uploads are blocked
• You are informed clearly
• An upgrade path is shown

Limits are enforced automatically and consistently.

They are not negotiable per user.

File Size & Type Rules

To protect system stability and fairness:

• Images have a maximum size limit
• Videos have a larger but controlled limit
• Only specific file formats are allowed

If you attempt to upload:

• An unsupported file type
• A file that is too large
• A corrupted file

The system will reject it and explain why.

Ownership & Control

Every file in your Media Library:

• Is tied to your account
• Can be renamed by you
• Can be deleted by you
• Cannot be edited by other users

Administrators may intervene in cases of abuse.

There is no public browsing of user libraries.

Public URLs & Sharing

Each file receives a public URL after upload.

This allows you to:

• Use the file inside Dev Space
• Embed it in projects
• Share it externally if needed

Important:

• The URL does not grant edit access
• Deleting a file permanently invalidates its URL
• Media is not discoverable publicly without the direct link

What Users Should Expect

When using the Media Library, expect:

• Clear plan-based limits
• Visible usage counts
• Immediate feedback on failed uploads
• Predictable rename and delete behavior
• No silent overrides

If an upload fails, it is usually because:

• Your plan limit has been reached
• The file type is unsupported
• The file exceeds size limits

The Media Library is a support system for learning.

Use it deliberately, not casually.

Technical Lessons are a specialized learning layer inside the platform.

While regular video lessons teach programming concepts, Technical Lessons focus on real technical execution and engineering workflows.

They demonstrate how real systems are built, configured, and operated in practical environments.

These lessons are designed to expose learners to real developer tools, infrastructure, and production thinking.

What Technical Lessons Are For

Technical Lessons help you understand the practical systems behind modern development.

They typically demonstrate:

• Developer workflows
• System setup and configuration
• Engineering tools used in real projects
• Infrastructure and deployment processes
• Technical productivity systems

These lessons focus less on theory and more on real-world execution.

Examples of Technical Lesson Topics

Technical Lessons may cover areas such as:

• ChatGPT workflow engineering
• Prompt system design
• Termux development environments
• GitHub version control workflows
• VPS server configuration
• Cloudflare deployment strategies
• Developer productivity systems

These topics expose learners to tools and environments commonly used by professional developers.

Video + Technical Documentation

Each Technical Lesson combines video demonstration with structured technical documentation.

Alongside the video, lessons may include:

• Step-by-step explanations
• Command-line examples
• Configuration references
• Technical notes and breakdowns
• Architecture explanations

This allows learners to watch the process and also read structured explanations.

Technical Categories

Technical Lessons are grouped into categories based on the type of system or discipline being demonstrated.

Examples of categories may include:

• AI Systems
• ChatGPT Engineering
• Development Environments
• Cloud Infrastructure
• DevOps & Deployment
• Engineering Workflows

Categories help organize technical knowledge and allow learners to explore related topics easily.

Access & Subscription Levels

Technical Lessons follow the same subscription-based access rules used throughout the platform.

Each lesson declares a required plan level.

This means:

• Free users may access introductory technical lessons
• Higher plans unlock deeper technical systems demonstrations
• Some advanced lessons may require higher subscription tiers

If a lesson requires a higher plan level, the interface will clearly indicate that it is locked.

What Users Should Expect

When watching Technical Lessons, expect:

• Real system demonstrations
• Practical engineering explanations
• Tools and workflows used by developers
• Technical breakdowns beyond basic programming
• Step-by-step demonstrations of technical processes

These lessons are designed to expand your understanding of how real software systems are built and operated.

Approach them with curiosity and a willingness to explore the broader engineering landscape.

The Student Notepad is your private knowledge workspace inside the platform.

It allows you to record ideas, document lessons, and maintain technical notes as you learn and build.

The Notepad functions like a developer’s engineering notebook.

Every note belongs only to you and cannot be seen by other users.

What the Notepad Is For

The Notepad helps you document your learning process and technical discoveries.

Typical uses include:

• Writing lesson summaries
• Recording commands or code snippets
• Documenting debugging discoveries
• Saving useful technical references
• Organizing development experiments

Developers who document their thinking learn faster and solve problems more efficiently.

Note Organization

The Notepad allows you to organize notes using folders and tags.

Folders group notes into broad categories.

• Lesson Notes
• Deployment Commands
• Linux Experiments
• Ideas & Concepts
• Debugging Notes

Tags provide a lightweight way to label notes by topic.

Tags are entered as simple keywords separated by commas.

For example:

• javascript
• nginx
• deployment
• laravel
• cloudflare

Tags allow you to locate related notes quickly even if they are stored in different folders.

Writing Notes

Notes support Markdown formatting.

This allows you to write structured technical documentation.

• Headings for structure
• Lists for organization
• Code blocks for commands
• Inline code formatting
• Tables and technical notes

The editor also provides a preview mode so you can see the formatted result while writing.

Automatic Saving

The Notepad automatically saves your changes while you work.

Autosave activates when you modify:

• The note title
• The content of the note
• Folder assignment
• Tags

This prevents accidental data loss and ensures your notes remain safe.

Pinned Notes

Important notes can be pinned.

Pinned notes appear at the top of your Notepad dashboard.

This allows you to keep frequently referenced material easily accessible.

Exporting Notes

Notes can be exported for backup or external use.

Supported export formats include:

• TXT (plain text)
• Markdown

Exporting allows you to archive important technical documentation outside the platform if needed.

What Users Should Expect

When using the Notepad, expect:

• Private notes visible only to your account
• Automatic saving of your work
• Clear folder organization
• Flexible tagging for quick search
• Reliable editing and preview tools

The Notepad is designed to help you build a long-term technical knowledge base.

Use it consistently to document your learning journey.