In Part 1 of this series, we built a shared GitLab CI repository and included it in multiple projects.

Now comes the real challenge — customization.

Every developer eventually says:

“Hey, I need to skip the deploy stage just for this repo.”

“Can we change the Docker image for the frontend build?”

If your shared CI templates are too rigid, teams will either fork them or hack local workarounds.

Neither is fun to maintain.

In this post, I’ll show you how we made our centralized CI repo flexible, so each project can tweak what it needs without breaking the core logic.

Recap: Where We Left Off

We had a shared repository called ci-templates, included like this:

include:
  - project: 'tapin/ci-templates'
    ref: 'v1.0.0'
    file: '/.gitlab-ci.yml'

This gave us consistent pipelines across all services.

But some projects needed small adjustments — different images, skipped stages, or extra scripts.

Time to make our shared templates parameterized.

Step 1 — Add Customizable Variables

Variables are the easiest way to let downstream projects configure behavior.

Here’s a snippet from templates/build.yml:

# templates/build.yml
variables:
  BUILD_IMAGE: docker:24
  ENABLE_DOCKER_PUSH: "true"

build_app:
  stage: build
  image: $BUILD_IMAGE
  services:
    - docker:dind
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - if [ "$ENABLE_DOCKER_PUSH" = "true" ]; then docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"; fi

Now any project can override these defaults in its .gitlab-ci.yml:

variables:
  BUILD_IMAGE: node:22-alpine
  ENABLE_DOCKER_PUSH: "false"

This simple pattern covers 80% of real-world customization needs.

Step 2 — Use extends: for Job Overrides

Sometimes you need deeper changes — for example, running an extra command or switching the deploy logic entirely.

That’s where extends: comes in.

In ci-templates we defined reusable job “bases”:

# templates/test.yml
.test_base:
  stage: test
  image: python:3.12
  script:
    - pytest -v

In a downstream repo, we can now extend and modify it:

unit_tests:
  extends: .test_base
  script:
    - echo "Running with custom settings"
    - pytest --maxfail=1 --disable-warnings -q

This merges the upstream definition with local changes — keeping inheritance clean and maintainable.

Step 3 — Conditional Jobs with rules:

Some repos don’t deploy at all (e.g., internal libraries).

Others deploy to different environments.

We used rules: to make deploy jobs optional:

# templates/deploy.yml
deploy_production:
  stage: deploy
  image: alpine
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$ENABLE_DEPLOY == "true"'
      when: on_success
    - when: never

Then in each project:

variables:
  ENABLE_DEPLOY: "false"  # skip deploy for this project

This gave teams full control — no copy-paste, no if-else chaos.

Step 4 — Add Template Parameters with !reference

Another useful trick: !reference lets you reuse script sections without rewriting them.

For instance:

.build_steps:
  script:
    - echo "Linting..."
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .

build_and_push:
  stage: build
  image: docker:24
  services: [ "docker:dind" ]
  script:
    - !reference [.build_steps, script]
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

It’s like calling a function inside YAML.

This keeps your core jobs modular and easier to maintain.

Step 5 — Include Multiple Templates Conditionally

When projects differ significantly (e.g., Node.js vs Python), we split templates per tech stack and conditionally include them.

Example in the project .gitlab-ci.yml:

variables:
  TECH_STACK: "python"

include:
  - project: 'tapin/ci-templates'
    ref: 'v1.0.0'
    file:
      - '/templates/common.yml'
      - '/templates/${TECH_STACK}.yml'

GitLab dynamically expands ${TECH_STACK} and picks the right file.

That way, frontend and backend teams use the same system, but load their own specialized templates.

Step 6 — Safe Rollouts and Versioning

We learned early that one mistake in a shared pipeline can break everything.

So, we implemented a staged rollout strategy:

1. Sandbox project: test every change there first.
2. Tag releases (v1.0.0, v1.1.0, etc.) in the ci-templates repo.
3. Projects gradually upgrade by changing ref: manually.

For example:

include:
  - project: 'tapin/ci-templates'
    ref: 'v1.1.0'
    file: '/.gitlab-ci.yml'

This allowed us to move fast but never break existing pipelines.

Step 7 — Debugging Included Pipelines

When something breaks, the first instinct is to look at the local .gitlab-ci.yml —

but remember, your jobs come from multiple includes.

Use GitLab’s “CI Lint” → “Include configuration” feature.

Paste your local file there — it expands all includes and shows the final merged YAML.

It’s a life-saver when debugging variable inheritance or job duplication.

Step 8 — Bonus: Custom Job Templates for Teams

Once the foundation was stable, teams started adding their own shared jobs under ci-templates/team/.

Example:

templates/
├── team/
│   ├── data.yml
│   ├── platform.yml
│   └── devops.yml

Each file defined team-specific steps — linting conventions, deployments, or security scans.

This structure kept autonomy while preserving consistency.

Lessons Learned

A few takeaways after scaling shared CI across 30+ repos:

• Start small. One template for build/test is enough. Expand later.
• Document every variable. Downstream users need clear guidance.
• Always version and test. Don’t include main unless you enjoy chaos.
• Encourage feedback. Your CI repo is a shared product — treat it like one.
• Automate validation. A bad YAML merge can take down multiple pipelines.

Final Thoughts

Centralizing GitLab CI/CD wasn’t just a technical improvement — it was cultural.

It taught our team to think in systems, not silos.

Today, every new project at Tapin starts with a 5-line .gitlab-ci.yml,

and yet it inherits the full power of our production-grade pipeline.

include:
  - project: 'tapin/ci-templates'
    ref: 'v2.0.0'
    file: '/.gitlab-ci.yml'

That’s it. CI in seconds, with years of refinement baked in.

When your organization grows, your CI pipelines tend to grow with it — and sometimes they grow in all directions.

At Tapin, we started with a handful of projects — an API here, a worker there — each with its own .gitlab-ci.yml.

Over time, every repository had slightly different pipelines. A typo here, a missing variable there, and maintenance quickly became a nightmare.

So, we decided to centralize our GitLab CI/CD configuration into one reusable repository — a single source of truth that every service could include and customize when needed.

This article (Part 1 of 2) explains exactly how we did it:

how to create a shared CI repo, include it in other projects, and keep it version-safe.

Why Centralize GitLab CI?

If you manage more than a few services, you’ve probably run into this pattern:

api/.gitlab-ci.yml
frontend/.gitlab-ci.yml
worker/.gitlab-ci.yml

All three might define the same jobs: build, test, deploy, etc.

When one needs a tweak — say a new Docker image tag — you must update all three.

Centralization solves that.

Instead of duplicating, you write those jobs once in a common repo and let everyone else include it.

Step 1 — Create the Shared CI Repository

We created a new repo called ci-templates.

Its purpose: hold every reusable CI definition.

Here’s the structure we started with:

ci-templates/
├── .gitlab-ci.yml
├── templates/
│   ├── build.yml
│   ├── test.yml
│   └── deploy.yml
└── README.md

The root .gitlab-ci.yml acts as an entry point that includes the sub-templates:

# ci-templates/.gitlab-ci.yml
include:
  - local: 'templates/build.yml'
  - local: 'templates/test.yml'
  - local: 'templates/deploy.yml'

Each file inside templates/ defines one stage or job.

For example, templates/build.yml:

# templates/build.yml
stages:
  - build

build_app:
  stage: build
  image: docker:24
  services:
    - docker:dind
  script:
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This file is now reusable in any project, no copy-paste required.

Step 2 — Include It in a Downstream Project

In each project (e.g., api, frontend), we replaced the entire .gitlab-ci.yml with a single include: statement.

Example for the api repository:

# api/.gitlab-ci.yml
include:
  - project: 'tapin/ci-templates'
    ref: 'v1.0.0'        # Pin to a version tag for safety
    file: '/.gitlab-ci.yml'

And that’s it.

Once committed, the project automatically gets all stages and jobs from the ci-templates repo.

GitLab merges the included YAMLs at runtime — as if you had written them locally.

Step 3 — Define Shared Variables

We added global variables inside ci-templates/.gitlab-ci.yml so every job could rely on consistent environment settings:

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  IMAGE_TAG: "$CI_COMMIT_SHA"

If a project needs a different value, it can simply override it in its own .gitlab-ci.yml (we’ll cover this in Part 2).

Step 4 — Pin Versions with ref

One major lesson we learned early:

Never use ref: main for production pipelines.

If someone updates ci-templates, all projects that include main instantly change — sometimes breaking builds.

Instead, always use a tag or commit SHA:

include:
  - project: 'tapin/ci-templates'
    ref: 'v1.0.0'
    file: '/.gitlab-ci.yml'

Then, when you release new CI updates, bump the tag (v1.1.0, v1.2.0, etc.) and let projects upgrade when ready.

This versioning approach gave us stability and predictability across dozens of services.

Step 5 — Test Before You Roll Out

Before merging new templates, we always test them in a sandbox project that uses the same include.

We even built a small CI validation job inside ci-templates:

validate_ci:
  stage: test
  image: registry.gitlab.com/gitlab-org/ci-cd/gitlab-ci-lint
  script:
    - curl --header "PRIVATE-TOKEN: $TOKEN" \
      --form "content=$(cat .gitlab-ci.yml)" \
      https://gitlab.com/api/v4/ci/lint

This ensures our shared templates always stay syntactically valid.

Step 6 — Organize by Functionality

As the repo grew, we split templates by domain:

templates/
├── docker/
│   ├── build.yml
│   └── publish.yml
├── test/
│   ├── python.yml
│   └── go.yml
└── deploy/
    ├── staging.yml
    └── production.yml

Each project could include just what it needed:

include:
  - project: 'tapin/ci-templates'
    ref: 'v1.0.0'
    file:
      - '/templates/docker/build.yml'
      - '/templates/test/python.yml'

This modular structure kept the pipeline lightweight and flexible.

Results

By the time we finished Part 1 of this journey, we had:

• One centralized CI repo reused by more than 20 services.
• Unified Docker build standards and naming conventions.
• Easier maintenance: fix once, apply everywhere.
• Safer rollouts thanks to versioned includes.

In Part 2, I’ll show you how we made those shared templates customizable — letting each team override variables, toggle stages, and extend jobs without touching the core.

A Practical Framework to Keep Cursor (and Any AI) Aligned with Your Vision

AI-powered coding assistants like Cursor, GitHub Copilot, and Codeium are transforming how developers write software.

They generate functions, design APIs, and even refactor architectures in seconds.

But here’s the problem: AI doesn’t understand boundaries.

Without a clear framework, it will happily rename your core modules, rewrite business logic, or swap your ORM for a shiny new one — because technically, it’s not wrong.

If you’ve ever told an AI “just fix this part” and ended up with a refactored project that broke five other things… you know exactly what I mean.

This article introduces a structured process to turn AI from a chaotic “code generator” into a disciplined teammate who follows your standards, respects your architecture, and delivers what you actually want.

The Core Problem: AI Doesn’t Know Context

AI models are amazing at local reasoning — they can see patterns in a single file, optimize loops, and infer relationships.

But they don’t have your mental map of the project. They don’t know why your architecture looks the way it does, or why one function must never be renamed.

That’s why they “improve” things you never asked for.

The solution isn’t to fight AI — it’s to give it a frame: a set of guardrails that define your project’s identity, architecture, and rules of engagement.

The Solution: A Two-Layer Framework

We use two layers to control AI development:

1. Project Rules (The Law) — A fixed document (PROJECT_RULES.md) that defines what the project is, what tools it uses, and what can/can’t be touched.
2. Task Protocol (The Procedure) — A structured way of asking for changes so each request stays scoped, predictable, and reviewable.

Layer 1 — The Project Rules File

Think of PROJECT_RULES.md as your constitution.

It’s what every AI and developer must obey.

Service Mission

Explain what this service does, who uses it, and what can never go wrong.

Example: “ Wallet Service manages internal user balances. It must guarantee transaction consistency. Downtime should never result in lost or duplicated transactions.”

Sensitivity & Compliance

List what’s legally or operationally risky.

Handles personal and financial data. Withdrawal requests require human approval. OTP codes must not be logged.

Responsibility & Boundaries

Define what this service owns — and what it does not.

Owns wallet balance and ledger. Does NOT handle SMS, PDF invoices, or user authentication.

Architecture & Tech Stack

Lock the language, frameworks, and folder structure.

Go 1.23 + chi. No ORM. Folder layout: /src/domain, /src/app, /src/infrastructure, /src/interfaces.

Code Quality & Runtime Rules

Define coding discipline: error handling, transactions, logs, tests, and performance.

All DB writes must use explicit transactions. Functions must stay under 50 lines. Logs must be JSON-formatted.

Collaboration Contract with the AI

Explain how the AI must deliver code.

No renaming without permission. Every response must include full file content (// FILE: path) and a final summary.

Once written, this file becomes the truth.

AI tools like Cursor can then be told:

“Follow PROJECT_RULES.md. Never deviate unless explicitly allowed.”

Layer 2 — The Task Protocol

Most chaos happens not in the rules, but in how you ask.

A vague prompt like “Add withdrawal support” invites disaster.

Instead, every request should follow this six-part structure:

CONTEXT: 
Where we are, and what the project does.

GOAL:
The purpose of this task (what we want to add/change).

SCOPE:
Exactly which files or folders the AI may touch.

DO NOT TOUCH:
Which files, modules, or layers must stay untouched.

DELIVERABLE:
Expected output (e.g., full code, migration file, or summary).

FORMAT:
How to present it (full file content, `// FILE:` headers, and summary).This keeps the AI inside its box.

This keeps the AI inside its box.

Example Task (for Cursor or Any AI IDE)

CONTEXT:
We are in the Wallet Service project. Follow PROJECT_RULES.md strictly.

GOAL:
Add a new "Top-Up Request" feature. A user can request to recharge their wallet. The system should create a pending record but not credit the balance yet.

SCOPE:
Create files under /src/app/topup, /src/domain/topup, /src/infrastructure/repo/topup_repo.go, and /src/interfaces/http/topup_handler.go.

DO NOT TOUCH:
Existing wallet logic, transaction manager, or authentication.

DELIVERABLE:
Show the FULL final content of each file created/modified.
Prefix each with `// FILE: path/to/file.go`.
At the end, add a SUMMARY with:
- request/response schema
- data flow
- TODOs or unimplemented validation.

FORMAT:
Code only + final SUMMARY. No commentary.

No guesswork. No refactoring surprises. No scope creep.

The Deep Insight

AI isn’t dangerous because it’s wrong.

It’s dangerous because it’s too confident when it’s slightly wrong.

Your job is to narrow its confidence range — to define where it’s allowed to be creative and where it must stay obedient.

This framework achieves that balance.

Bonus: Automating Rule Extraction

If you’re a product owner or tech lead who doesn’t want to manually write all these rules, use the following Mother Prompt.

This prompt will make the AI interview you through 32 deep questions — and automatically generate your PROJECT_RULES.md.

The Mother Prompt

Copy and paste this into Cursor, ChatGPT, or any LLM IDE, then say:

“Run this for my [project name].”

You are my "Project Rules Extractor & Builder."

Your job has TWO phases:

PHASE 1 — ASK ME QUESTIONS  
PHASE 2 — GENERATE PROJECT_RULES.md

GLOBAL RULES:
- Do NOT skip questions or assume answers.
- If an answer isn’t provided, write "Not specified yet".
- Follow the process strictly.

PHASE 1:
Ask me 32 questions in 6 steps about:
1. Service Mission  
2. Sensitivity & Risk  
3. Boundaries & Ownership  
4. Architecture & Technology  
5. Code Quality & Process  
6. Collaboration Contract

Ask all questions from each step in one message, wait for my answers, then continue.

PHASE 2:
After all 32 answers, create PROJECT_RULES.md with these sections:
1. SERVICE MISSION  
2. SENSITIVITY & COMPLIANCE  
3. RESPONSIBILITY & BOUNDARIES  
4. ARCHITECTURE & TECH STACK (LOCKED)  
5. CODE QUALITY & RUNTIME RULES  
6. COLLABORATION CONTRACT WITH THE AI

If anything was "Not specified yet", include it as-is — do not guess.  
Stop after producing PROJECT_RULES.md. No code generation.  

How to Use It

1. Paste the Mother Prompt into your AI tool (Cursor, ChatGPT, Claude, etc.).
2. Say something like:

“Run this for the Wallet Service project.”

1. Answer the 32 questions step-by-step.
2. When done, the AI will generate your full PROJECT_RULES.md.
3. Save it in your repo root and tell Cursor:

• “Follow PROJECT_RULES.md strictly for all future tasks.”

That’s it — your AI will finally build your software, not its own version of it.

Final Thoughts

AI copilots like Cursor can be revolutionary — but only when you give them structure.

Without discipline, they’ll code faster… in the wrong direction.

With Project Rules and Task Protocol, you transform AI from a code generator into a collaborative engineer who understands context, architecture, and responsibility.

Stop building software by AI.

Full Prompt for start project with all policy :

You are my "Project Rules Extractor & Builder."

Your job has TWO phases, and you MUST ALWAYS do them in order:

PHASE 1 — ASK ME QUESTIONS  
PHASE 2 — GENERATE PROJECT_RULES.md

IMPORTANT GLOBAL RULES:
- Do NOT skip any question.
- Do NOT invent answers.
- Do NOT assume. If the answer is not given yet, explicitly say "Not specified yet" and move on.
- Keep everything structured and deterministic. No marketing tone. No fluff.
- You MUST stay inside the process described below. Do not switch topics.

====================================================
PHASE 1 — ASK ME QUESTIONS
====================================================

You will ask me 32 questions in 6 steps.  
You MUST go step by step.  
In each step:
1. Ask ALL questions from that step in a single message.
2. Wait for my answer.
3. After I answer, continue to the next step.

Do NOT mix steps. Do NOT jump ahead.

The steps and questions are:

-------------------------
STEP 1. SERVICE MISSION / VISION
(Goal: understand what this service is and why it exists)

Q1. What real-world problem does this service solve? (Describe in practical terms, not buzzwords.)
Q2. Who is the main user/consumer of this service? (Human end-user, internal service, admin panel, mobile app, etc.)
Q3. Is this service exposed directly to the internet, or is it only called internally by other services?
Q4. If this service goes down, what breaks in the business?
Q5. What is the one thing this service absolutely must ALWAYS get right, even in failure conditions? (For example: "wallet balance must never be wrong")

-------------------------
STEP 2. SENSITIVITY / RISK / NO-GO ZONES
(Goal: find legal, security, business red lines)

Q6. Does this service handle sensitive data? (money, identity, personal data, location, transaction history, etc.)
Q7. What data or actions, if leaked or modified, would create legal, financial, or trust damage?
Q8. Which actions MUST require human approval and must NOT be fully automated? (like withdrawal approval, deleting accounts, etc.)
Q9. Are there any logging/retention constraints? (For example: "Do not log OTP", "We cannot store live GPS longer than X", "GDPR applies", etc.)

-------------------------
STEP 3. BOUNDARIES / RESPONSIBILITY
(Goal: define what belongs to this service and what does NOT)

Q10. Which responsibilities are OWNED by this service and must live here (it is the source of truth for them)?
Q11. Which related responsibilities are explicitly NOT owned here and should live in other services? (For example: sending SMS, generating PDF invoices, doing KYC, etc.)
Q12. Which other internal services or external systems does this service depend on, and for what? (e.g. Auth service for user_id, Pricing service for shipping quote...)
Q13. Is this service going to expose a public API that external clients/mobile apps call directly, or is it internal-only?
Q14. Do you expect this service to version its API (v1, v2...), or is versioning not required yet?

-------------------------
STEP 4. ARCHITECTURE / TECHNOLOGY / FOLDERS
(Goal: lock in tech stack, folder layout, style of separation)

Q15. What language and main framework MUST be used? (Example: Go 1.23 + chi; Python + Django; Node + Express)
Q16. Do you want a clean layered architecture (domain / application / interfaces / infrastructure), or are you ok with a simpler "routes + repo" style?
Q17. Should business logic be separated from HTTP handlers and database code? (YES/NO. If YES, describe how you imagine that separation.)
Q18. Which layering model do you prefer?  
     Option A: domain (entities, rules) / application or usecase (orchestration) / interfaces (HTTP, gRPC...) / infrastructure (DB, Redis...)  
     Option B: a simpler structure (e.g. api/, repository/, models/)  
     Option C: [Describe your own]
Q19. What folder structure do you want at the top level of the repo? (List folders exactly as you want them named. Example:
      /src/domain
      /src/app
      /src/infrastructure
      /src/interfaces
      /migrations
      /tests
   Or your own.)
Q20. Which frameworks / libraries are ALLOWED?
Q21. Which frameworks / libraries are FORBIDDEN? (Example: "No ORM like gorm", "No FastAPI", "No mongoose", etc.)
Q22. Do you have naming/style rules? (Struct names, file names, package names, snake_case vs camelCase, etc.)

-------------------------
STEP 5. QUALITY / PROCESS / SAFETY
(Goal: define how strict we are in code behavior)

Q23. In a tradeoff, which is more important: fast delivery or absolute correctness/safety? (Choose one, and explain.)
Q24. Do you want functions to stay small and single-responsibility, or is large/monolithic ok for now?
Q25. How should error handling work? (Bubble errors up and log them? Swallow noncritical errors? Panic/throw?)
Q26. How should database transactions be handled?  
     - A) A transaction is created at the top of the use case and passed down explicitly  
     - B) Each repository method starts/commits transactions internally  
     - C) You don't care / Not decided
Q27. What is your policy on tests for now?  
     - A) Every feature MUST ship with tests  
     - B) For now, code can ship without tests, but each response must include a TODO list of recommended tests  
     - C) We will add tests later manually; don't even generate TODOs
Q28. What is your logging policy?  
     - Structured JSON logs with consistent fields?  
     - Simple print/debug logs ok for now?  
     - Sensitive fields must NEVER be logged?
Q29. Do you have performance expectations?  
     (Max response time? Max RPS you expect on critical paths? Any "must be under 1s" constraints?)

-------------------------
STEP 6. COLLABORATION CONTRACT WITH THE AI
(Goal: control how code is generated so it doesn't go rogue)

Q30. Are renames and refactors of existing code allowed WITHOUT your explicit approval? (YES/NO. If NO, say "No rename/refactor unless I explicitly approve it.")
Q31. When the AI thinks something unrelated needs improvement, should it:
     - A) apply the refactor directly
     - B) leave the code unchanged and just write a TODO suggestion? (Pick A or B.)
Q32. When the AI returns code for a task, how should it present the output?
     - Should it show FULL FILE CONTENT for every created/modified file, prefixed with `// FILE: path/to/file.ext`?
     - Should it also include a final SUMMARY section with:
       • request/response schema
       • data flow / lifecycle
       • TODOs / risks that are NOT implemented yet
     Describe exactly what format you expect.

END OF PHASE 1.

After asking all 32 questions and receiving all answers, proceed to PHASE 2.


====================================================
PHASE 2 — GENERATE PROJECT_RULES.md
====================================================

Now you MUST generate a single document called PROJECT_RULES.md.

PROJECT_RULES.md MUST have the following sections, in this exact order and with these exact headings:

1. SERVICE MISSION
   - What this service does
   - Who uses it
   - Critical guarantee (the thing that must never be wrong)
   - Impact of downtime

2. SENSITIVITY & COMPLIANCE
   - Sensitive data handled
   - Legal / trust / security red lines
   - Actions requiring human approval
   - Logging & retention constraints

3. RESPONSIBILITY & BOUNDARIES
   - What this service OWNS (source of truth)
   - What this service EXPLICITLY does NOT own
   - Upstream/downstream dependencies (who we call / who calls us)
   - Public vs internal API
   - API versioning expectations

4. ARCHITECTURE & TECH STACK (LOCKED)
   - Approved language, runtime version, frameworks, libraries
   - Forbidden libraries / patterns
   - Required folder structure (list folders exactly)
   - Required layering model (e.g. domain / application / interfaces / infrastructure)
   - Naming conventions
   - Rule: "Do not introduce new frameworks or libraries unless explicitly approved"
   - Rule: "Consistency with existing code is more important than theoretical best practice"

5. CODE QUALITY & RUNTIME RULES
   - Error handling policy
   - Transaction handling policy
   - Logging policy
   - Testing policy
   - Performance expectations / SLAs
   - Priority: speed vs correctness
   - Function size / readability expectations

6. COLLABORATION CONTRACT WITH THE AI
   - Refactor / rename policy
   - Allowed scope of a single task (which folders the AI may touch per request)
   - Output format requirement:
     * For each touched file, AI MUST output the FULL final content
     * Each file must be prefixed with `// FILE: relative/path`
     * AI MUST also output a final `SUMMARY` section with:
       - request/response schema
       - data flow in plain language
       - TODO suggestions and security concerns
   - Rule: "If you think something outside the current task needs improvement, DO NOT change it. Add it as a TODO in SUMMARY."

IMPORTANT:
- If any answer from PHASE 1 was "Not specified yet", you MUST still include that line in PROJECT_RULES.md rather than guessing. Explicitly write "Not specified yet".
- The PROJECT_RULES.md MUST be clean, direct, and implementation-focused. Do NOT include marketing language.
- After you produce PROJECT_RULES.md, STOP. Do not generate any code.

====================================================

GENERAL BEHAVIOR REMINDERS:
- Stay focused. Do not invent features, endpoints, or capabilities not explicitly confirmed.
- You are not allowed to "improve" scope for me automatically. You only gather, and then you summarize into PROJECT_RULES.md.
- You are not allowed to generate code in PHASE 1.
- You are not allowed to skip PROJECT_RULES.md in PHASE 2.

BEGIN NOW.

How to Use the Project Rules in Cursor

Once your PROJECT_RULES.md is ready, you can now connect it directly to your Cursor workflow — turning the AI from a generic code generator into a reliable, rule-following teammate.

Here’s how to do it step-by-step 👇

🔹 1. Place the Rules in Your Repository

Save the file at the root of your project (right beside go.mod, README.md, or package.json).

Cursor automatically reads files in your workspace as context, so having PROJECT_RULES.md there means it can “see” it.

🔹 2. Instruct Cursor to Follow It

Whenever you create or edit code with Cursor, start your request with this line:

Follow PROJECT_RULES.md strictly before doing anything.

Then describe your task using the structured format below.

Cursor works best when your instructions are precise and bounded.

🔹 3. Use the Task Protocol for Every Change

Use this exact structure in each AI prompt (either in chat or command mode):

CONTEXT:
We are in the ShortLink project. Follow PROJECT_RULES.md strictly.

GOAL:
Add a new endpoint to show detailed analytics per short link (aggregated by OS, browser, and country).

SCOPE:
You may only modify:
- /src/app/analytics/
- /src/domain/analytics/
- /src/interfaces/http/analytics_handler.go
- /tests/analytics_test.go

DO NOT TOUCH:
- Any existing link creation or redirect logic.
- Database schema or migrations.
- Authentication or Keycloak integration.

DELIVERABLE:
Provide full final content for every file you create or modify.
Each file must begin with `// FILE: path/to/file.go`
and end with a SUMMARY section explaining:
- request/response schema
- data flow
- TODOs for things outside this scope

FORMAT:
Code only + final SUMMARY. No extra commentary.

🔹 4. Review and Commit

Cursor will generate full files instead of small diffs.

That means you can:

• copy/paste directly into your codebase,
• review line-by-line before committing,
• and verify that nothing outside your defined scope changed.

If it ever modifies something unexpected, just reply:

“That violates PROJECT_RULES.md — revert that change.”

The AI will automatically correct itself.

🔹 5. Repeat for Every Feature

Every new feature or fix you want to add should be a separate, scoped request.

This prevents chain reactions like “auto refactors” or “silent architecture changes.”

With time, you’ll build a stable rhythm:

• PROJECT_RULES.md defines how to work.
• Each Task Prompt defines what to build.

Together, they form a repeatable and predictable development process — AI code that always fits your architecture.

💡 Pro Tip

If your project grows, you can version your rules file (e.g., PROJECT_RULES_v2.md) and tell Cursor:

“Follow PROJECT_RULES_v2.md instead of the previous one.”

This keeps your rules auditable — just like versioned API contracts.

💬 Example Conversation in Cursor

Let’s look at what a real interaction looks like when your PROJECT_RULES.md is in place and you’re giving Cursor a new task.

👤 Developer Prompt

Follow PROJECT_RULES.md strictly.

CONTEXT:
We are in the ShortLink project.

GOAL:
Implement a new endpoint to fetch a list of all short links created by the current user, including their creation date, destination URL, and click count.

SCOPE:
Allowed to modify:
- /src/app/link_list/
- /src/domain/link/
- /src/interfaces/http/link_list_handler.go
- /tests/link_list_test.go

DO NOT TOUCH:
- Redirect flow
- Analytics logic
- Database schema
- Any code outside these folders

DELIVERABLE:
Provide full final content of each modified or created file.
Prefix each file with `// FILE: path/to/file.go`
Then include a SUMMARY that describes:
- Request and response schema
- Data flow from HTTP → usecase → repository
- TODOs for out-of-scope improvements

FORMAT:
Code only + final SUMMARY. No commentary.

🤖 Cursor’s Ideal Response

✅ Understood. Following PROJECT_RULES.md strictly.

// FILE: src/app/link_list/usecase.go
package link_list

import (
    "context"
    "shortlink/src/domain/link"
)

type Service struct {
    repo link.Repository
}

func NewService(repo link.Repository) *Service {
    return &Service{repo: repo}
}

func (s *Service) ListUserLinks(ctx context.Context, userID string) ([]link.LinkSummary, error) {
    links, err := s.repo.FindByUser(ctx, userID)
    if err != nil {
        return nil, err
    }
    return links, nil
}

// FILE: src/interfaces/http/link_list_handler.go
package http

import (
    "encoding/json"
    "net/http"
    "shortlink/src/app/link_list"
    "shortlink/src/infrastructure/auth"
)

type LinkListHandler struct {
    service *link_list.Service
}

func NewLinkListHandler(service *link_list.Service) *LinkListHandler {
    return &LinkListHandler{service: service}
}

func (h *LinkListHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    userID, err := auth.ExtractUserID(r.Context())
    if err != nil {
        http.Error(w, "unauthorized", http.StatusUnauthorized)
        return
    }

    links, err := h.service.ListUserLinks(r.Context(), userID)
    if err != nil {
        http.Error(w, "internal error", http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    _ = json.NewEncoder(w).Encode(links)
}

📄 SUMMARY

Request: GET /api/v1/links

Response:

[
  { "id": "abc123", "long_url": "https://example.com", "clicks": 24, "created_at": "2025-10-24T12:00:00Z" },
  { "id": "xyz789", "long_url": "https://tayanloo.ir", "clicks": 8, "created_at": "2025-10-23T10:15:00Z" }
]

Flow:

HTTP handler → extracts user ID from JWT context → calls link_list.Service.ListUserLinks() → repository fetches all links for that user.

TODOs:

• Add pagination and sorting support later.
• Add unit tests for ListUserLinks() and HTTP handler.

✅ What This Shows

• The AI followed all folder boundaries (src/app, src/interfaces, src/domain).
• It didn’t rename or move any files.
• It returned full file contents and a structured summary.
• It clearly separated logic across layers.

This is exactly the kind of disciplined, reproducible output you get when AI development follows a Project Rules + Task Protocol model.

🧠 Why This Method Works (Psychology of AI Obedience)

When you use an AI coding assistant like Cursor, you’re not talking to a human developer.

You’re talking to a pattern engine — one that tries to complete your intent based on its statistical understanding of code, not your architectural vision.

That’s why most AI failures aren’t bugs… they’re boundary violations.

The Core Problem

AI doesn’t know where your project begins and ends.

It doesn’t know that your architecture was carefully designed for scalability, or that you intentionally avoided an ORM because of performance.

To the AI, all solutions look equally valid if they “compile and look clean”.

That’s the root cause of the chaos — no awareness of context or authority.

The Fix: Turn Context into Law

When you write a PROJECT_RULES.md, you’re not just describing the system —

you’re codifying authority.

You’re giving the AI an explicit hierarchy:

“You may think. You may propose.

But you may not override the law.”

This shifts the AI’s behavior from “creative improvisation” to contract execution.

The model stops guessing and starts complying.

The Role of the Task Protocol

The Task Protocol acts as the courtroom procedure for every change.

It ensures every request has:

• Context: where the task lives
• Scope: what’s allowed
• Boundaries: what’s forbidden
• Deliverable: what’s expected
• Format: how to report it

When you do this, AI is no longer “coding freely” — it’s executing a scoped contract under supervision.

Why It Feels So Reliable

This method works because it mirrors how disciplined teams already operate:

• The PROJECT_RULES.md acts like a system design document.
• Each task prompt acts like a technical spec or Jira ticket.
• Cursor becomes the junior engineer who strictly follows the spec.

You’ve basically recreated a mini software organization —

except your intern is an LLM with infinite speed and zero ego.

The Hidden Bonus: Reproducibility

If you ever onboard a new AI, or even a new human developer, you can hand them this setup and say:

“Here’s the constitution.

Here’s how we file tickets.

Everything else is forbidden.”

They’ll produce the same structure, the same architecture, and the same tone of code — every time.

That’s engineering reproducibility, something traditional AI prompts could never guarantee.

💡 Final Thought

AI doesn’t need to “understand” your system — it just needs to obey the shape of it.

When you define that shape clearly, you don’t have to hope for good results;

you can guarantee them.

This framework turns AI from a creative assistant into a systematic builder —

the difference between chaos and craftsmanship.

✨ Closing Thoughts — Discipline Over Freedom

AI doesn’t need more freedom.

It needs better direction.

The future of software development won’t be “AI replacing engineers.”

It’ll be engineers who know how to direct AI — who can define the rules, the scope, and the architecture so precisely that even a machine can’t mess it up.

Tools like Cursor are not magic; they’re amplifiers.

If you give them noise, they’ll amplify chaos.

If you give them structure, they’ll amplify excellence.

That’s the real secret:

Don’t let AI build for you.

Teach it to build with you.

Discipline creates velocity.

Standards create freedom.

And structure — not spontaneity — is what makes AI a true partner in engineering.

Data validation plays a critical role in data processing, especially when working with large datasets. Whether you’re building machine learning models, performing statistical analysis, or simply cleaning data, ensuring that your data conforms to specific rules is crucial to avoid errors and ensure accurate results. In the Python ecosystem, Pandera is an emerging library designed specifically for data validation with Pandas DataFrames. This article will explore Pandera, its features, and how it can be used to validate and enforce rules on your data.

What is Pandera?

Pandera is an open-source Python library built to provide schema validation for Pandas DataFrames and Series. It allows you to define a set of validation rules (schemas) for your data and then easily validate whether the data conforms to those rules. Pandera integrates seamlessly with Pandas, making it an excellent choice for data scientists and analysts who are working with structured data and need to ensure that their DataFrames meet certain expectations.

While Pandas itself offers some basic tools for data validation (e.g., checking for NaN values, data types), Pandera takes data validation to the next level by providing declarative schemas and a more formalized, readable approach to specifying rules. This results in less code, fewer errors, and more readable validation logic.

Key Features of Pandera

1. Declarative Schema Definition

• In Pandera, you define a schema for your DataFrame or Series using Python class definitions. The schema specifies the types and constraints for each column, making it clear what the expected structure of your data should be.

2. Type Checking and Constraints

• Pandera enables you to specify not just the type of data each column should hold (e.g., integer, string, datetime), but also additional constraints like minimum or maximum values, string length, regular expressions for pattern matching, and more.

3. Custom Validation

• You can create custom validation rules to enforce more complex requirements that go beyond built-in type checks and constraints.

4. Integration with Pandas

• Pandera works directly with Pandas DataFrames and Series, which means you don’t need to convert your data to any other format before validating it. It seamlessly fits into your existing Pandas workflow.

5. Error Handling

• When validation fails, Pandera provides clear error messages indicating which columns and rows failed validation and why. This makes it easy to pinpoint and fix issues in your data.

6. Support for Missing Data

• Pandera can validate the presence or absence of NaN values in your data and specify whether a column should contain missing data or not.

7. Column-Level Validation

• You can specify validation rules for individual columns, including setting valid ranges, allowed values, or patterns that the data must adhere to.

Installation

Pandera can be installed using pip, the Python package manager. To install Pandera, run the following command:

pip install pandera

This will install the latest version of Pandera and its dependencies.

Using Pandera: A Basic Example

To get started with Pandera, let’s take a look at a basic example. Suppose we have a DataFrame with data about individuals’ ages and names, and we want to validate that the age column contains integers and that the name column contains strings.

import pandera as pa
import pandas as pd

# Define the schema for the DataFrame
class PersonSchema(pa.SchemaModel):
    age: pa.typing.Series[int]  # Age should be an integer
    name: pa.typing.Series[str]  # Name should be a string

# Sample data
data = {
    "age": [25, 30, 22, 35],
    "name": ["Alice", "Bob", "Charlie", "David"]
}

df = pd.DataFrame(data)

# Validate the DataFrame
schema = PersonSchema.to_schema()
schema.validate(df)

In this example, the schema PersonSchema defines two columns: age and name, with specified data types of int and str, respectively. The validate method checks whether the df DataFrame adheres to these rules.

Advanced Features of Pandera

1. Column Constraints

In addition to type validation, Pandera allows you to define additional constraints for each column. For example, you can define a minimum or maximum value for a numerical column, restrict string lengths, or check that a column follows a specific regular expression pattern.

class AdvancedSchema(pa.SchemaModel):
    age: pa.typing.Series[int] = pa.Field(gt=18, le=100)  # Age should be between 18 and 100
    name: pa.typing.Series[str] = pa.Field(str_length=3)  # Name length should be at least 3 characters

• gt and le specify greater than and less than or equal constraints for the age column.
• str_length specifies that name should be at least 3 characters long.

2. Handling Missing Data

Pandera allows you to specify how to handle missing data. For instance, you can specify that a column should never contain missing values (nullable=False) or that missing values are allowed (nullable=True).

class DataWithMissing(pa.SchemaModel):
    age: pa.typing.Series[int] = pa.Field(nullable=False)  # Age should never be null
    name: pa.typing.Series[str] = pa.Field(nullable=True)  # Name can be null

3. Custom Validators

Pandera supports custom validators for columns. For example, you can define a validator to ensure that the data in a column meets a certain condition.

import re

def valid_email(email: str) -> bool:
    return bool(re.match(r"[^@]+@[^@]+\.[^@]+", email))

class EmailSchema(pa.SchemaModel):
    email: pa.typing.Series[str] = pa.Field(check=valid_email)  # Check that the email is valid

Here, the valid_email function is used to check that each email address in the email column matches a regular expression pattern.

Why Use Pandera?

1. Improved Data Quality

• By using Pandera, you can ensure that your data adheres to specific rules and formats, leading to better data quality and fewer issues during analysis or modeling.

2. Simplified Workflow

• Pandera simplifies data validation by allowing you to define schemas once and reuse them across your codebase, reducing the need for repetitive checks.

3. Clearer Error Messages

• When validation fails, Pandera provides clear error messages, making it easy to identify and fix problems in your data.

4. Consistency and Reusability

• Pandera allows you to create reusable schemas that can be applied across different datasets. This helps maintain consistency in your data validation logic.

5. Integration with Pandas

• Since Pandera integrates directly with Pandas, it fits naturally into the typical data manipulation pipeline used by data scientists and analysts.

Conclusion

Pandera is an excellent tool for anyone working with Pandas and needing to enforce strict data validation rules. By providing a clean, declarative way to define schemas and validate data, Pandera simplifies the process of ensuring that your data meets specific standards. Whether you are performing data cleaning, building machine learning models, or analyzing large datasets, Pandera makes it easier to catch errors early in your pipeline and maintain high-quality data.

With its powerful features, such as type checking, column constraints, and custom validation, Pandera is a must-have for anyone working with structured data in Python.

In this article, we’ll take a closer look at SSH-Manager, its unique features, and how you can use it to optimize your workflow.

What Is SSH-Manager?

SSH-Manager is an open-source project hosted on GitHub by htayanloo. It’s designed to simplify the management of SSH connections. Instead of remembering multiple IP addresses, ports, usernames, and connection options, SSH-Manager allows users to store and manage their SSH connections in a structured and intuitive way.

The tool is particularly useful for those who frequently connect to different servers and find themselves constantly referencing notes or scrolling through `bash_history` to find previous SSH commands. SSH-Manager addresses this issue by offering an organized interface that allows easy access to your most-used connections.

Key Features of SSH-Manager

SSH-Manager is more than just a list of SSH commands — it comes packed with features that help manage and optimize SSH sessions. Here are some of the highlights:

1. Connection Storage & Tagging

With SSH-Manager, you can save all your SSH connections into a centralized database. Each connection can be tagged, making it easy to filter and locate specific servers based on usage. For example, you can use tags like `production`, `staging`, or `testing` to classify your different environments.

2. Command Shortcuts

One of the core features of SSH-Manager is its ability to create custom shortcuts for connections. No longer will you need to type out lengthy SSH commands repeatedly. Instead, you can assign a memorable alias to each server and connect with a simple command like `ssh-manager connect production-db`.

3. Flexible Management Options

SSH-Manager supports several convenient connection options:
 — Current Terminal Window: You can initiate a connection in the same window.
 — New Window/Tab: Start a new connection in a separate terminal window or tab, making it easier to manage multiple servers simultaneously.
 — Multiple Connections with Tabs: If you need to log into multiple servers, SSH-Manager allows you to do so, each in its own tab, so you stay organized.
 — tmux Integration: The tool can integrate with `tmux` for power users who want more sophisticated terminal multiplexing capabilities.

4. `bash_history` Integration

SSH-Manager can parse your `bash_history` to detect past SSH commands, automatically saving the frequently-used ones into its database. This feature ensures that you can always refer back to past connections without rummaging through your command history manually.

5. Easy Listing and Editing

Listing all your saved SSH connections is just a command away. SSH-Manager also makes it easy to edit connection details — whether it’s a username, a port, or a server address — without directly manipulating config files.

Getting Started with SSH-Manager

To get started with SSH-Manager, you can follow the instructions on the [GitHub repository](https://github.com/htayanloo/SSH-Manager). Here’s a brief overview of the process:

1. Installation:
SSH-Manager is written in Go, so the first step is to have Go installed. You can then clone the repository and build it using Go’s standard toolchain. The commands are straightforward and are detailed on the GitHub page.

2. Adding Connections:
After installation, you can add your first connection using the `add` command. This is where you can set tags, names, and shortcuts for easy retrieval later.

3. Connecting:
Use `ssh-manager connect [name]` to quickly connect to any server you’ve added. The intuitive command structure and tab completion make the process fast and painless.

Why Use SSH-Manager?

If you’re still wondering why you should use SSH-Manager, consider the following scenarios:

- **Reduce Mental Overhead**: Managing SSH configurations for a dozen or more servers can be overwhelming. SSH-Manager helps you centralize all connection details in one place, reducing mental load and increasing efficiency.
- **Increase Productivity**: Quickly connecting to servers with a shortcut means fewer typos, fewer failed login attempts, and a smoother workflow.
- **Powerful Tagging System**: For those who manage both production and testing environments, tags make it easy to distinguish between the two without error. You can avoid the potentially disastrous mistake of confusing production with a non-production server.

Resources for Learning More

The GitHub repository for [SSH-Manager](https://github.com/htayanloo/SSH-Manager) includes a detailed README file that provides more specific usage examples, installation instructions, and even some advanced usage tips. It’s worth browsing through the repository and checking out the Issues and Discussions tabs as well, which contain community-provided questions and insights that may enhance your understanding of the tool.

You can also explore other tutorials on Medium about SSH best practices, which will provide context and further motivation to streamline your SSH workflow.

Conclusion

SSH-Manager is an essential tool for developers and system admins who want to make their lives easier. By centralizing SSH connections, simplifying command inputs, and offering flexible connection options, SSH-Manager is the modern replacement for traditional, manual SSH configuration methods. If you frequently connect to multiple remote servers, you owe it to yourself to give SSH-Manager a try.

Visit the [GitHub page](https://github.com/htayanloo/SSH-Manager) to get started, and see how SSH-Manager can improve your workflow today.

Introduction
PyFilesystem2 is a powerful and flexible library for working with filesystems in Python, allowing developers to easily manage files and directories. One of the attractive features of PyFilesystem2 is its support for in-memory filesystems, which can be useful for various purposes such as testing, caching data, and rapid processing. In this article, we will explore how to use PyFilesystem2 to store video frames captured by OpenCV in an in-memory filesystem.

Prerequisites
To get started, we need to install two libraries: PyFilesystem2 and OpenCV. You can install these libraries using pip:

pip install fs opencv-python

Creating an In-Memory Filesystem
First, we need to create an in-memory filesystem. This can be done using the `MemoryFS` class from the PyFilesystem2 library. Below is an example of how to create an in-memory filesystem and store a simple file in it:

from fs.memoryfs import MemoryFS

# Create an in-memory filesystem
mem_fs = MemoryFS()

# Create and write to a file
with mem_fs.open(‘example.txt’, ‘w’) as file:
file.write(‘Hello, PyFilesystem2!’)

Capturing Video Frames with OpenCV
To capture video frames, we will use the OpenCV library. OpenCV is an open-source library used for image and video processing. Here is how to capture video frames from a camera or video file:

import cv2

# Open the camera or video file
cap = cv2.VideoCapture(0) # For camera, replace with video file name for a video file

# Check if the video source is opened
if not cap.isOpened():
print(“Error: Could not open video source.”)
exit()

# Read a frame
ret, frame = cap.read()

# Check if the frame was read successfully
if ret:
cv2.imshow(‘Frame’, frame)
cv2.waitKey(0) # Display the frame until a key is pressed
else:
print(“Error: Could not read frame.”)

Storing Frames in an In-Memory Filesystem
Now that we can capture video frames, we need to store these frames in the in-memory filesystem. To do this, we will first convert the frames to an image format (e.g., PNG) and then store them in the filesystem.

import cv2
import numpy as np
from fs.memoryfs import MemoryFS

# Create an in-memory filesystem
mem_fs = MemoryFS()

# Open the camera or video file
cap = cv2.VideoCapture(0) # For camera, replace with video file name for a video file

# Check if the video source is opened
if not cap.isOpened():
print(“Error: Could not open video source.”)
exit()

frame_count = 0

while True:
# Read a frame
ret, frame = cap.read()

# Check if the frame was read successfully
if not ret:
break

# Convert the frame to PNG format
_, buffer = cv2.imencode(‘.png’, frame)
png_data = buffer.tobytes()

# Store the frame in the in-memory filesystem
file_name = f’frame_{frame_count:04d}.png’
with mem_fs.open(file_name, ‘wb’) as file:
file.write(png_data)

frame_count += 1

# Release the video source
cap.release()

# List the stored files
print(mem_fs.listdir(‘/’))

Conclusion
In this article, we explored how to use PyFilesystem2 to create an in-memory filesystem and store video frames captured by OpenCV. This approach allows you to temporarily store video frames quickly, which can be very useful for real-time and temporary processing tasks. PyFilesystem2 is a powerful tool that enables you to easily manage various types of filesystems and leverage them in your projects.

Introduction

Numpy is a widely-used library in Python, known for its robust capabilities in scientific computing. One of its key features is the flatten() method, which allows us to convert multi-dimensional arrays into one-dimensional arrays. This article delves into the uses and implementation of this method.

Definition and Use

The flatten() method in Numpy linearly arranges a multi-dimensional array into a single-dimensional array. It's primarily used for simplifying complex data structures into more manageable and analyzable formats.

Code Examples

Basic Example

import numpy as np

# Creating a 2D array
arr = np.array([[1, 2, 3], [4, 5, 6]])

# Using the flatten method
flattened_arr = arr.flatten()

print("Original Array:\n", arr)
print("Flattened Array:\n", flattened_arr)

Application in Image Processing

import numpy as np
from PIL import Image

# Loading an image and converting it to a numpy array
image = Image.open('path/to/image.jpg')
image_arr = np.array(image)

# Flattening the image array
flattened_image_arr = image_arr.flatten()

print("Original Image Dimensions:", image_arr.shape)
print("Flattened Image Dimensions:", flattened_image_arr.shape)

Applications

1. Data Processing: Transforming multi-dimensional data into a one-dimensional format for easier analysis and processing.
2. Image Processing: Converting images into linear arrays for use in machine learning algorithms.
3. Data Flattening for Storage: Compressing data into simpler formats for more efficient storage.

Conclusion

The flatten() method in Numpy is a powerful tool for converting multi-dimensional arrays into one-dimensional formats. Its applications range from data analysis, to image processing, and more. Because of its simplicity and efficiency, the flatten() method is a fundamental tool for any developer working with multi-dimensional data.

Introduction:

Managing access to resources and sensitive information in information systems is a fundamental challenge in information security. Two important models for managing access to information in computer systems are Role-Based Access Control (RBAC) and Parameterized Role-Based Access Control (PRBAC). In this article, we will examine and compare these two models, highlighting their strengths and weaknesses, and provide a sample implementation of PRBAC.

Section 1: Role-Based Access Control (RBAC)

RBAC is a conceptual model for access management based on roles. In RBAC, users are assigned to roles, and each role has specific access rights to resources. The strengths of RBAC include:

• Simplicity: RBAC simplifies access management due to its straightforward structure.
• Flexibility: This model allows organizations to create custom roles and make changes to access rights easily.
• Efficiency: RBAC enables organizations to efficiently manage access in the best possible way.

Section 2: Parameterized Role-Based Access Control (PRBAC)

PRBAC is an extension of RBAC that operates in a parameterized manner. In PRBAC, access rights and roles depend on specific user or resource attributes. The strengths of PRBAC include:

• Fine-Grained Access: PRBAC allows organizations to manage access to resources based on specific user or resource attributes.
• High Precision: This model provides high precision in access management and is stronger from a security perspective.
• Flexible Configurations: PRBAC allows organizations to make access changes without significant structural modifications.

Section 3: Comparing RBAC and PRBAC

• Flexibility: RBAC is less flexible compared to PRBAC because access rights are assigned to roles, and making changes can be complex.
• Fine-Grained Access: PRBAC excels in providing fine-grained access control, while RBAC offers more coarse-grained control.
• Complexity: PRBAC is more complex to implement due to its parameterized nature, and management may be challenging.

Section 4: Sample PRBAC Implementation

As an example of a simple PRBAC implementation in Python, we create an access management system for user data. (Similar to the previous PRBAC example)

# Define roles
roles = {
    "admin": ["read", "write", "delete"],
    "editor": ["read", "write"],
    "viewer": ["read"]
}

# Define user attributes
users = {
    "user1": {"role": "admin", "location": "office"},
    "user2": {"role": "editor", "location": "home"},
    "user3": {"role": "viewer", "location": "office"}
}

# Define parameterized access
access_control_list = {
    "read": {"location": ["office"]},
    "write": {"location": ["office", "home"]},
    "delete": {"location": ["office"]}
}

# Function to check access
def check_access(user, action, resource_location):
    if user in users:
        role = users[user]["role"]
        if action in roles[role]:
            if "location" in access_control_list[action]:
                if resource_location in access_control_list[action]["location"]:
                    return True
    return False

# Test access control
user = "user1"
action = "delete"
location = "office"
if check_access(user, action, location):
    print(f"{user} has permission to {action} in location {location}.")
else:
    print(f"{user} does not have permission to {action} in location {location}.")

In this sample PRBAC implementation, we utilize user and resource attributes (location) to determine access rights, demonstrating how PRBAC enables fine-grained access control based on specific attributes.

Conclusion:

In comparison to RBAC, PRBAC offers fine-grained access control and higher precision, making it stronger from a security standpoint. However, PRBAC requires a more complex implementation and may pose management challenges. The choice between RBAC and PRBAC should be based on specific requirements and the complexity of the target system.

If you’re a developer or QA engineer, you’re probably familiar with API testing. API testing is a critical aspect of software development and ensures that your application’s backend functions as expected. However, it can be challenging to manage and automate API tests, especially when you’re dealing with a large number of endpoints or complex request and response payloads.

This is where PactumJS comes in. PactumJS is an open-source testing tool that simplifies API testing. With PactumJS, you can write API tests in a clean, readable format that’s easy to understand and maintain. The tool’s API testing capabilities are designed to be intuitive and user-friendly, making it easy for both developers and QA engineers to use.

One of the unique features of PactumJS is its support for “contract testing.” Contract testing is a testing methodology that verifies the compatibility between the API provider and consumer. PactumJS provides an intuitive way to create and manage contracts between APIs, making it easy to ensure that the APIs you rely on work as expected.

PactumJS is also highly extensible. It integrates seamlessly with popular testing frameworks like Mocha and Jest and can be easily customized to fit your specific testing needs. Additionally, it supports a variety of request and response formats, including JSON, XML, and text.

Another notable feature of PactumJS is its ability to simulate network latency and failure conditions. This allows you to test how your application handles real-world scenarios, such as slow or unreliable network connections. This feature is particularly useful for testing applications that rely heavily on API calls.

PactumJS is free and open-source, making it an excellent choice for developers and QA engineers on a budget. The tool has an active community of contributors who are continually adding new features and improving the tool’s functionality.

In conclusion, PactumJS is a powerful and flexible API testing tool that simplifies the testing process for developers and QA engineers. Its intuitive syntax, support for contract testing, and extensibility make it an excellent choice for anyone looking to streamline their API testing process. Whether you’re a seasoned developer or just starting, PactumJS is definitely worth checking out.

example of a Login and Add to Cart API:

Login API:

Endpoint: POST /api/login Request Body:

{
  "email": "user@example.com",
  "password": "password123"
}

Response:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
  "token_type": "bearer",
  "expires_in": 3600
}

In this example, the user provides their email and password in the request body. If the credentials are valid, the API returns an access token that can be used to authenticate subsequent requests.

Add to Cart API:

Endpoint: POST /api/cart/add Headers:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Content-Type: application/json

Request Body:

{
  "product_id": "123",
  "quantity": 2
}

Response:

{
  "message": "Product added to cart successfully.",
  "cart_items": [
    {
      "product_id": "123",
      "quantity": 2,
      "price": 19.99
    }
  ]
}

In this example, the user is authenticated using the access token returned by the Login API. They then provide the product ID and quantity of the item they want to add to their cart. If the request is successful, the API returns a message confirming that the product was added to the cart, along with a list of all items currently in the cart.

Introduction GitLab CI/CD is a powerful tool that can automate your software development workflow. One common use case for GitLab CI is building Docker images, which can then be deployed to various environments. In this article, we will walk through the process of building a Docker image with an automatically incremented version number using GitLab CI.

Prerequisites To follow this tutorial, you will need:

• A GitLab account with access to a GitLab repository
• Docker installed on your local machine or on a remote server
• Basic knowledge of Docker and GitLab CI/CD

Creating a GitLab CI Configuration File The first step is to create a GitLab CI configuration file in your repository’s root directory. You can name the file .gitlab-ci.yml. This file will define the build pipeline for your Docker image.

Defining a Build Job The next step is to define a job in the GitLab CI configuration file that will build the Docker image using the docker build command. Here's an example of what the job might look like:

build:
  image: docker:latest
  stage: build
  script:
    - docker build -t myimage:$CI_COMMIT_SHORT_SHA .

In this example, the job is called build and it uses the docker:latest image as a base image. The job runs in the build stage of the pipeline.

The script section of the job specifies the commands to be run. In this case, the docker build command is used to build the Docker image. The -t option is used to tag the image with a name and a version number. The $CI_COMMIT_SHORT_SHA variable is used to generate a unique version number based on the current Git commit.

Using Git Tags to Generate Version Numbers In the previous example, the version number was generated using the $CI_COMMIT_SHORT_SHA variable, which is unique to each Git commit. While this approach works, it can be difficult to track which version corresponds to which Git commit.

A better approach is to use Git tags to generate version numbers. Git tags provide a way to mark specific points in your Git repository’s history. By tagging a specific commit with a version number, you can easily track which version corresponds to which commit.

Here’s an updated example of the build job that uses Git tags to generate version numbers:

build:
  image: docker:latest
  stage: build
  script:
    - VERSION=$(git describe --tags --abbrev=0 | awk -F '[-.]' '{print $1"."$2"."$3+1}')
    - docker build -t myimage:$VERSION .
    - git tag $VERSION

In this example, the VERSION variable is generated using the git describe command. The --tags option tells Git to include tags in the output. The --abbrev=0 option tells Git to use the full tag name.

The awk command is used to extract the version number from the Git tag. The awk command splits the tag name into three parts, separated by hyphens and dots. The first part is the major version, the second part is the minor version, and the third part is the patch version. The awk command increments the patch version by one and sets the VERSION variable to the new version number.

The docker build command is then used to build the Docker image, and the image is tagged with the new version number. Finally, the git tag command is used to create a Git tag with the new version number.

Conclusion In this article, we’ve walked through the process of building a Docker image with an automatically