Changelog

Ask in a Chat, or choose New application on the Applications page, and Jigward builds the tool as an Application: a page, a database of its own that the page reads and changes, and named actions. You change it by talking to Jigward in the conversation beside it.

An Application belongs to one Context and is shared with the team or kept personal. Every change is a new version, and an earlier version can be restored. A CSV file attached in its conversation can be loaded into its data.

Limits: It is a tool for the team’s own work, not a general-purpose app platform, and it is never opened to anyone outside its Context.

Ask Jigward to check something at a set time: once, every 15 minutes or more, or on chosen days of the week, in a named time zone. This standing instruction is a Duty. Create one on a Context’s Duties page, or ask in a Chat or a Task to keep an eye on something and Jigward creates it. Everyone working in the Context sees it.

Each run is a wake. A wake reads first, without a workspace, and ends with nothing new, a report or a problem. Nothing new leaves a line in the Duty’s history; a report goes to the Chat or the Task the Duty came from. When the work needs engineering, the wake gives an ordinary Task.

A Duty can be run now, edited or cancelled, and its history shows every wake.

Limits: A Duty works only in its own Context. Duties replace Jigward’s former reminders, and Jigward no longer reminds anyone on its own.

While it works on a Task, or when you explain something in a private Chat, Jigward can keep a small piece of knowledge about the product, filed under a topic such as a feature’s name. It reaches the whole Context and records where it came from, what settled it and when.

Later work in the same Context finds it again. When the product changes, a newer statement replaces the old one, which is kept unchanged as history. A memory from a private Chat names no Chat and quotes nothing from it.

Limits: A mention in Slack or Jira does not write memory, and there is no screen yet where a member reads what Jigward remembers.

A small Task is one piece of work Jigward carries out directly. When the work calls for more, Jigward lays it out in stages and may follow a workflow: a recipe for a kind of work, used as guidance rather than a fixed route. It can drop a step that does not fit and add one the recipe lacks.

Jigward has built-in workflows, and a Task can save a practice that will recur, for its Context or for the whole organization, such as one a pull request review taught it. Every revision is kept, and a Task keeps the revision it followed.

Jigward chooses the model level of each stage, Standard, Deeper or Strongest, and records why.

Limits: Workflows have no screen of their own and members do not edit them directly. Members do not choose a model.

An admin names the AWS account, its regions and the log group prefixes Jigward may read, and creates in that account a role that reads only log groups under those prefixes. Jigward keeps no AWS credential. The connection is checked before it is used, and a repository can be given the log groups that belong to it.

A Task searches the logs within a time window or runs a bounded Logs Insights query. The lines it read are kept on the Task as a file, and the Task shows each search with its account, log group, window and pattern.

Limits: Logs only, not metrics or alarms. A mention in Slack or Jira does not read logs.

An admin sets up a browser profile: a name, one or more https addresses, the Context whose Tasks may use it, and the secret values Jigward types there, such as a login. A Task in that Context opens the profile, reads the page, clicks, types and signs in, the way a QA engineer checks a change. Jigward types the values itself: the model names a field and never sees its value.

The Task keeps the session: a recording that replays on its Recording tab, the browser console log and any screenshots.

Limits: A session is not watched live, and sites behind a private network are out of reach.

The repository’s APIs tab shows the HTTP API its OpenAPI 3 documents describe, operation by operation, with parameters, request bodies and responses. Jigward reads a committed document, or one the repository’s springdoc or REST Docs tests generate. No model takes part, and Jigward never derives an API from controllers or other code.

The Dependencies tab shows each project root’s dependency tree as its build tool reports it: Maven with every scope, Gradle’s runtime classpath, and for npm the dependencies declared in package.json, at their declared ranges and without transitive ones. Jigward resolves nothing itself.

In a Task or a Chat, Jigward searches both and reads only what a question needs, including how a library reaches the project.

In a Slack channel an admin named for a Context, mention @Jigward. It reads the messages before the mention, then answers in the thread, asks a question when it needs one, or takes the request on as a Task, creating one if the thread has none. The Task’s questions, its wait for a merge and its report are posted back to the same thread.

Every message on a Task or in a Chat now names who wrote it: a member by their account name, a person from Slack or GitHub by the name their service gave, and Jigward as Jigward.

When a repository is added, and on every refresh, Jigward applies its Liquibase or Flyway migrations to an empty PostgreSQL database and reads back the tables, columns and foreign keys they define. A repository with several services gets one schema per module that has migrations of its own.

The repository’s Database tab shows each module’s reading and the commit its schema was read at. In a Task or a Chat, Jigward searches the schema by topic and reads only the tables a question needs.

Limits: PostgreSQL only, with Liquibase or Flyway only. Without such migrations there is no schema to read, and Jigward does not guess one from the code.

A Chat is a conversation between you and Jigward in one Context. No other member can open it, and it is still there when you come back.

Before it answers, Jigward reads what the question needs: the Context’s repositories at the head of their default branch, without starting a workspace, and public web pages. Each answer ends with the files and pages it read, each file with its commit, so a follow-up builds on the same sources.

When the conversation turns into work, Jigward proposes a Task as a card, and only Create task creates it. It can also add an instruction to a Task you already have. A Chat itself changes no repository.

Write what you need in your own words, in a Context. This is a Task, the unit of work Jigward carries through to a report.

Jigward starts from what it already read of the repository. When the work needs a working copy, it creates a workspace from the repository at the commit it last read, changes the code there, runs the repository’s own tests, and removes the workspace when the work ends. What it read, changed and ran stays on the Task.

Every code change arrives as a draft pull request on a branch of the Task’s own. Jigward never merges it: the Task waits as Awaiting code review and is done once a person merges. An investigation that changes nothing needs no pull request.

Sign in, and if you belong to no organization yet, Jigward asks for one thing: its name. The organization is created, you become its super admin, the role that runs the organization and pays for it, and your work starts in its Default Context.

Each person belongs to one organization. Registration is closed while Jigward is in closed testing.